In any event, if the AS is not one that the client believes that it has some
type of security context to, then it does not seem to be a huge issue.   If
C does not trust AS, then it should not be talking to it however it makes
that decision. We currently do not support the four corner model in the ACE
protocol, although I think that is a candidate for an extension draft in the
future.

-----Original Message-----
From: Ace <ace-boun...@ietf.org> On Behalf Of Stefanie Gerdes
Sent: Tuesday, September 8, 2020 2:33 AM
To: ace@ietf.org
Subject: Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

the hard-coded list of authorized AS' is only one possibility for
authorization on the client side. I think we agreed that it is not a very
good one. The client may also dynamically obtain if a certain AS is
authorized. In this case, it is useful for the client to know for which AS
it must search.

The unauthorized resource request mechanism also allows the server to
provide a nonce (the cnonce) to the client, that must afterwards be present
in the access token. A constrained server without wall clock time and time
synchronization mechanism can use it to determine if the access token is
fresh.

Viele Grüße
Steffi

On 09/08/2020 10:37 AM, John Mattsson wrote:
> Hi Stephanie,
> 
> Regarding the section that you quoted: "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."
> 
> Assuming C has access to a function M letting it determine whether an AS
has the authority to issue access tokens for a certain RS, this would
certainly partly mitigate DoS attacks. The attack would be a DoS attack on C
and M, but the attacker could not choose M.
> 
> The problem is that:
> - if C has access to such a function M that can provide a link between AS
and RS, the whole mechanism with sending the AS address in an error message
seems completely redundant.
> - If C does not have access to such a function M, the mechanism with
sending an address in a spoofable error message seems like a very dangerous
attack vector for DDoS attacks.
> 
> The only implementation of M that would make use of an error message would
be if the error message contained something like sign(AS, RS), but this is
something that is not discussed in the draft.
> 
> Cheers,
> John
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> 

-- 
Stefanie Gerdes                 Tel: +49 421 218 63906
TZI Universität Bremen          E-Mail: ger...@tzi.de
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

_______________________________________________
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

Reply via email to