Subject: [Ace] ACE Framework Review

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 10 Oct 2018 16:24:05 +0200

Hi,

I looked through the ACE framework document. I think there are some open
issues that need to be addressed. I will try to summarize the main
issues below. We provided a rough analysis of the DTLS profile in [1],
which may also be interesting (many of the issues mentioned there were
already fixed in the meantime).

The protocol elements of the framework assume that responses are bound
to requests in the sense that the receiver of a response can be certain
that response actually belongs to a certain request. This requirement
should be mentioned, e.g., in the security considerations.

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.

Validity of the access token (Token Expiration, Section 5.8.3): There
seem to be additional requirements here that are currently not
mentioned. It is not clear how RS determines the freshness of
introspection messages (and how fresh they are). Also, the token
introspection approach is particularly vulnerable to DoS attacks since
introspection messages must be exchanged to validate every token. This
should at least be mentioned in the security considerations.
The sequence number approach has the problem that an attacker may
withhold new tokens from RS. In this case, old tokens are infinitely
valid. This is particularly damaging because C may have a strong
interest to withhold new tokens and can easily do so by not relaying
them to RS. This approach therefore must not be used unless there is an
additional communication channel between RS and AS that regularly
informs RS which the most recent sequence number is.

Authorization of the AS on the RS side: in the ACE framework, RS checks
the integrity of the access token (e.g., section 4, section 6, Appendix
B: Resource Server). RS must also check that the access token stems from
an AS that is authorized by RO to provide the token. If RS accepts
tokens from authorization servers that are not approved by RO, the
solution is not secure. Introspection messages must also stem from an AS
that is approved by RO.

Access token validation: Section 5.8.1 should point out that RS must
check the integrity of the token and validate that it stems from AS that
is authorized by RO. Also, it would be helpful if the section also
contained information how a server must react to missing fields, e.g.,
missing authenticity of the token or tokens from unknown authorization
servers.

Confidentiality of access tokens:
In the access token, confidentiality is only demanded for symmetric
keys. The security considerations should point out that other data in
the access token may be confidential and then require protection as well.

Authorization Rules in Access Token: The framework should mention in
section 5.6.2 that the authorization rules that are presented to RS in
the scope of the access token must reflect RO's decisions.

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 tokens. If introspection messages are used to
check the validity of access tokens, the use of the authz-info resource
amplifies the risk of DoS attacks since RS must send a message to its AS
for every received token. These problems should be mentioned in the
security considerations. The preferred mitigation should be that the
authz-info resource is only used for protected communication. This does
obviously not work for the RPK mode. In the PSK mode, RS should be able
to decide that it uses the authz-info resource only for protected updates.
* How must the authz-info resource be protected? E.g., an attacker that
is able to modify the resource may change or delete access tokens. The
framework leaves the protection of the resource to the profiles, but I
think some general advice can be offered by the framework.

Validity of the access information:
It seems that the people who wrote the framework did not consider that
the keying material is not only provided to RS but also to C.
How does C determine if the keying material it receives from AS is still
valid? The access token response may comprise an expires_in
field that contains the validity period of the access token in seconds
(RFC 6749), but does not specify the validity period of the keying
material. But even if the validity periods are equal, C does not know
when the access token was generated. Also, the use of the expires_in
field is optional. Without protection, the access information is
infinitely valid. C may use outdated and maybe compromised keying
material to communicate with RS. The framework should provide
information how C determines if the keying material is still valid.
Also, C must check if the keying material it has for a communication
partner is still valid before sending a request.

The framework should also mention that C must determine if AS is
authorized by its owner to provide keying material concerning RS to C.

It is not clear how C makes plain to AS with which RS it wants to
communicate. C may specify the intended audience in the token request
using the req_aud parameter. How is RS represented in this case?
C and AS must have a common understanding how RS is identified,
otherwise C may communicate with the wrong RS!
IP addresses may change and therefore are not suitable. If AS specifies
identifiers for RS, C must securely obtain this knowledge.
The framework must point out that AS must check if the keying material
that it provides to C in the access token response actually refers to
the RS that C wants to communicate with. The problem of mixups
concerning the RS must be mentioned in the security considerations.
Also, the framework should give advice how this problem may be addressed.

Confidentiality of unauthorized requests:
The data that the client sends to the RS in an unauthorized resource
request may be confidential (e.g., because others must not know the
requested resources). The framework should mention in the security
considerations that the client must not send confidential data in the
unauthorized resource request.

Viele Grüße
Steffi

[1] https://dx.doi.org/10.14722/diss.2018.23006

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 22 Oct 2018 15:07:38 +0200

> already fixed in the meantime).

Thank you for your review. Sorry for the long response time. Answers 
inline. I also tried to add issues in the issue tracker, but github 
seems to be experiencing trouble at the moment.

/Ludwig

> should be mentioned, e.g., in the security considerations.
Agree. I will add a paragraph.

> material do they need to use? 

The first one I agree with. However the other questions seem more 
specific to the commSec solution to me, which would put them into the 
profiles.

> The framework should point out that all

Are there claims that do not influence security?

The specification says (section 4):

    The consent of the resource owner, for giving a client access to a
    protected resource, can be provided dynamically as in the traditional
    OAuth flows, or it could be pre-configured by the resource owner as
    authorization policies at the AS, which the AS evaluates when a token
    request arrives.  The resource owner and the requesting party (i.e.,
    client owner) are not shown in Figure 1.

I believe this is what you were looking for, if not please explain what 
is missing.

> introspection messages (and how fresh they are).

That would be up to the commSec protocol, also it is covered in the 
security considerations of RFC 7662. I will add a reference to those 
considerations in our security considerations section.

> Also, the token
> introspection messages must be exchanged to validate every token. 

This problem applies to regular OAuth introspection as well and is 
covered in the security considerations of RFC 7662.

> informs RS which the most recent sequence number is.
This is a best effort approach when the RS has no internal sense of 
time. Also the idea was that several client could submit tokens with an 
ever increasing unique serial number maintained by the AS. Thus even if 
one client would withhold it's newer tokens to keep the old ones from 
expiring, the other clients would eventually submit enough new tokens 
(with higher sequence numbers) so that the token expires.

AFAIK the RS with no internal clock at all is a very rare occurrence, 
thus you can usually expect some form of wallclock time, and thus 
implement an expiration based on "time-since-you-received-this-token".

> solution is not secure. Introspection messages must also stem from an AS

This is implicit, if the RS has the key that allows it to verify the 
integrity of the token that means that it is an AS approved by its RO.
I will try to add a sentence to make that more explicit.

> is authorized by RO. 

We can expand on this phrase I think: "The RS receiving the token MUST 
verify the validity of the token."

> Also, it would be helpful if the section also
This would be the following sentence in 5.8.1:
"If the token is not valid, the RS MUST respond with a response code 
equivalent to the CoAP code 4.01 (Unauthorized)."

> the access token may be confidential and then require protection as well.
This should be covered in RFC 6749  and RFC 6819 which are referenced in 
the security considerations.

> the scope of the access token must reflect RO's decisions.

That is already covered by the text in section 4 (see comment above).

> store large numbers of tokens.

A RS is not expected to store large numbers of tokens. Section 5.8.1 
specifies:

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

Thus the RS can adapt the number of tokens it stores to its constrained 
storage resources.

> If introspection messages are used to
> security considerations.

I will add a section describing the problem.

> The preferred mitigation should be that the

I don't think that will help, since somehow the initial access token 
must get to the RS. So even when passing it through the DTLS handshake 
(as with PSK in the DTLS profile) the same DoS risk exists.

> think some general advice can be offered by the framework.

I can add a paragraph on this in section 5.

> valid?

It is valid as long as you don't get a 4.01 (Unauthorized) from the RS.

> The access token response may comprise an expires_in

I would think that in most cases it is acceptable that the client just 
optimistically sends its request with the existing keying material and 
renews it if it gets back a 4.01.

Use cases where the security policy is such that this is unacceptable 
should use a specific profile that defines additional mechanisms for the 
client to check its tokens and associated keying material (e.g. by using 
client introspection).

> authorized by its owner to provide keying material concerning RS to C.

If C is configured to communicate with RS, this implies that the owner 
of C accepts the AS in charge of RS. Otherwise the owner of C shouldn't 
have configured C to communicate with RS in the first place.

> identifiers for RS, C must securely obtain this knowledge.

Identifying the RS (using the audience claim and the req_aud parameter) 
is application specific. Some applications may want to use public keys, 
others will want to use fixed identifiers that are manually assigned or 
otherwise generated.

The framework does not suggest IP addresses as a way to identify an RS.

> Also, the framework should give advice how this problem may be addressed.

I will add a paragraph describing the problem and giving some basic 
suggestions (such as public keys as identifiers).

> unauthorized resource request.

I can add a sentence about this, although it seems very obvious.

/Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Oct 2018 13:59:47 -0700

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Monday, October 22, 2018 6:08 AM
> To: [email-masked]
> Subject: Re: [Ace] ACE Framework Review
> 
> > I looked through the ACE framework document. I think there are some
> > open issues that need to be addressed. I will try to summarize the
> > main issues below. We provided a rough analysis of the DTLS profile in
> > [1], which may also be interesting (many of the issues mentioned there
> > were already fixed in the meantime).
> 
inline. I
> also tried to add issues in the issue tracker, but github seems to be
> experiencing trouble at the moment.
> 
> /Ludwig

> That would be up to the commSec protocol, also it is covered in the
security
> considerations of RFC 7662. I will add a reference to those considerations
in
> our security considerations section.

This seems to be a bit of an odd requirement to impose on the protocol and
not on the RS.  The RS should have some type of idea of when it last asked
the AS if it was valid and also some idea of when the AS said this was going
to expire relative to when it last asked.  If the RS asks twice and the AS
returns a cached answer that is on the AS and not on the RS.

An RS with no sense of time could still implement a counter and ask the AS
every nth access to the resource (potentially spreading that over all
accesses by anybody).

> > them to RS. This approach therefore must not be used unless there is
> > an additional communication channel between RS and AS that regularly
> This is a best effort approach when the RS has no internal sense of time.
Also
> the idea was that several client could submit tokens with an ever
increasing
> unique serial number maintained by the AS. Thus even if one client would
> withhold it's newer tokens to keep the old ones from expiring, the other
> clients would eventually submit enough new tokens (with higher sequence
> numbers) so that the token expires.
> 
> AFAIK the RS with no internal clock at all is a very rare occurrence, thus
you
> can usually expect some form of wallclock time, and thus implement an
> expiration based on "time-since-you-received-this-token".

Additionally one could use the clear everything after n accesses to
resources.

> Thus the RS can adapt the number of tokens it stores to its constrained

This might be a good place to reference the new core draft  - too many
requests - as a reasonable response for an overloaded server in this case.

> (as with PSK in the DTLS profile) the same DoS risk exists.

Going the DTLS handshake route might actually make things worse as you are
now doing lots of additional process on the server side since you have added
all of the DTLS work to the token validation work.

> client to check its tokens and associated keying material (e.g. by using

I think that the use of the expires_in field in an AS response should cover
this case sufficiently well for most cases where the client might care.  I
would agree that the failure of a request is a good clue that a new token
needs to be obtained.  I am not sure that it makes any sense to say that
keying material has expired for the RPK case.  It only makes sense to have
key lifetime for a POP symmetric token.  In that case I would expect that
the lifetime of the token and the key material to be the same.  I would not
think that a new token with expanded privileges on the same key material
should last beyond the original POP token.  This does mean that there will
need to be a more frequent DTLS negotiation but that is not difficult for a
simple PSK with no asymmetric key.

> The framework does not suggest IP addresses as a way to identify an RS.

There are two cases here that need to be thought about.  The first is that
the audience and the RS are synonymous.   In that case there is not a
problem here.  The second case is an audience that exists on multiple
servers. The question then is should the token be setup for a single RS or
for every RS that hosts the audience?  I would expect it to be the latter as
one could get a redirect at some point from RS1 to RS2 but it should not
require that a new token be obtained just that it be re-posted.   The
question you ask would only be if interest if one said that multiple RSs
hosted a single audience and they all had to be keyed separately.

Jim

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

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 24 Oct 2018 15:53:20 +0200

Hi Ludwig,

> specific to the commSec solution to me, which would put them into the

In Appendix C, you specify that the security protocol between C and RS
must provide encryption, integrity and replay protection. It would be
useful to list similar requirements for the communication between C and
AS and RS and AS.

In section 5 you state "Nevertheless, it is REQUIRED that the data
exchanged with the AS is encrypted and integrity protected. Does that
refer to both the communication between the AS and C and between the AS
and RS? It would be useful to clarify that in the sentence.

The client may specify a key in the request to the AS. The AS must
ascertain that the client that sent the request is associated with this
key. Otherwise a client may request tokens for other clients. Although
the client cannot gain access with these tokens without the
corresponding keying material, it may use the token for DoS attacks on
the resource server's authorization information endpoint. Since the
tokens are valid, RS cannot throw them away.

> I believe this is what you were looking for, if not please explain what

As I read it, this paragraph only addresses authorization information
that is meant for the server. The client may receive keying material for
RS from AS. In this case, C's owner, i.e., RqP, must authorize AS to
provide keying material to C.

> covered in the security considerations of RFC 7662.

It might be useful to mention that in the security considerations.

> implement an expiration based on "time-since-you-received-this-token".

I don't think it is reasonable to require that the RS must have multiple
clients to ensure that the mechanism works. If you expect the RS to have
a wallclock time, you may want to omit the sequence number approach. If
the mechanism only works when additional requirements are met, these
requirements must be mentioned.

If the RS calculates the expiration of the token from the time it
received the token (an appraoch which currently does not seem to be
mentioned in the document?), the approach is vulnerable to attacks where
an attacker manages to withhold messages.

> verify the validity of the token."

That sounds like a good idea.

> equivalent to the CoAP code 4.01 (Unauthorized)."

It would be useful to add when the RS can consider a token to be valid,
i.e., which requirements a token must meet to be valid.

> That is already covered by the text in section 4 (see comment above).

Section 5.6.2 describes how AS specifies the response to the client.
I think it would help to avoid implementation errors if the section
describes that the authorization rules that the AS defines in the access
token must reflect RO's decisions.

> Thus the RS can adapt the number of tokens it stores to its constrained

I don't really understand how storing at least one access token helps to
mitigate the problem of DoS attacks.

> (as with PSK in the DTLS profile) the same DoS risk exists.

If the client is not able to finish the DTLS handshake, the RS can throw
the token away immediately. Also, DTLS has some protection against DoS
attacks. If a resource is used, clients can upload large numbers of
tokens to the resource, and no protection against DoS attacks is
available. If the tokens are valid, the RS must in the worst case store
them until they expire, even if the client never tries to communicate
with RS.

> renews it if it gets back a 4.01.

You mean if the client communicates with a compromised RS, it just
continues to do so? I don't think that this is such a good idea. I think
the AS must check that the the keying material is valid at least as long
as the token and must then set the expires_in field to the remaining
lifetime of the token. Additionally, the AS should provide the time when
the token was issued in an iat field. A client that wants to communicate
with an RS must check if the keying material it has for the RS is still
valid.

> have configured C to communicate with RS in the first place.

And how does C know that a certain AS is in charge of RS?

Viele Grüße
Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 24 Oct 2018 15:53:29 +0200

Hi Jim,

> every nth access to the resource (potentially spreading that over all

A counter that RS starts before sending the introspection message would
help to solve this problem if a timeout is defined or if the
introspection message contains the lifetime of the token. If this is the
expected behavior of RS, it should be mentioned in the document.

> all of the DTLS work to the token validation work.

As I already pointed out in my response to Ludwig, transporting the
token in the DTLS handshake has the advantage that the RS can discard
the token if C is not able to finish the handshake. Also, DTLS has some
protection against DoS attacks. Uploading large amounts of access tokens
to a resource is very easy for a client.

> simple PSK with no asymmetric key.

RPKs do not have semantic information attached to them and they do
expire eventually. The AS must check if the keying material that it
provides to C is still valid at least as long as the token and then must
set the expires_in field to the remaining lifetime. To avoid attacks
where an attacker manages to withhold messages, the AS should specify
when the token was issued in an iat field.

> hosted a single audience and they all had to be keyed separately.

The audience seems to be some string that (not necessarily uniquely)
identifies RS. Appendix B states that the AS is expected to know which
audiences refer to the RS. I wonder how C knows which audience
identifies an RS. I think it is very important to point out that AS and
C must have a common understanding how RS is identified because
otherwise C will communicate with the wrong RS.

Viele Grüße
Steffi

---

From: Jim Schaad <[email-masked]>
Date: Thu, 25 Oct 2018 14:11:59 -0700

> From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
> Sent: Wednesday, October 24, 2018 6:53 AM
> To: Ludwig Seitz <[email-masked]>; [email-masked]
> >> 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?
> >
must
> provide encryption, integrity and replay protection. It would be useful to
list
> similar requirements for the communication between C and AS and RS and
> AS.

I would find this request quite reasonable.

> In section 5 you state "Nevertheless, it is REQUIRED that the data
exchanged
> with the AS is encrypted and integrity protected. Does that refer to both
the
> communication between the AS and C and between the AS and RS? It would
> be useful to clarify that in the sentence.
> 
ascertain
> that the client that sent the request is associated with this key.
Otherwise a
> client may request tokens for other clients. Although the client cannot
gain
> access with these tokens without the corresponding keying material, it may
> use the token for DoS attacks on the resource server's authorization
> information endpoint. Since the tokens are valid, RS cannot throw them
> away.

I completely agree with this and have made the same argument multiple times.

> 
> >
> >> 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.
> >>
> >
> > I believe this is what you were looking for, if not please explain
> > what is missing.
> 
> As I read it, this paragraph only addresses authorization information that
is
> meant for the server. The client may receive keying material for RS from
AS.
> In this case, C's owner, i.e., RqP, must authorize AS to provide keying
> material to C.
> 
> >
> >> introspection approach is particularly vulnerable to DoS attacks
> >> since introspection messages must be exchanged to validate every token.
> >
> > time. Also the idea was that several client could submit tokens with
> > an ever increasing unique serial number maintained by the AS. Thus
> > even if one client would withhold it's newer tokens to keep the old
> > ones from expiring, the other clients would eventually submit enough
> > new tokens (with higher sequence numbers) so that the token expires.
> >
clients
> to ensure that the mechanism works. If you expect the RS to have a
> wallclock time, you may want to omit the sequence number approach. If the
> mechanism only works when additional requirements are met, these
> If the RS calculates the expiration of the token from the time it received
the
> token (an appraoch which currently does not seem to be mentioned in the
> document?), the approach is vulnerable to attacks where an attacker
> manages to withhold messages.

The other day I was thinking about this and I am wondering if a server which
has this level of abilities would be more likely to just act as a client
posting it's information to some type of pub-sub server rather than acting
directly as a server which would be queried by other clients.  This is the
type of server one would expect to send most of its time sleeping and thus
trying to time talking to it correctly would be difficult.

> 
> >
> >> Authorization of the AS on the RS side: in the ACE framework, RS
> >> checks the integrity of the access token (e.g., section 4, section 6,
> >> Appendix
> >> B: Resource Server). RS must also check that the access token stems
> >> from an AS that is authorized by RO to provide the token. If RS
> >> accepts tokens from authorization servers that are not approved by
> >> RO, the solution is not secure. Introspection messages must also stem
> >> from an AS that is approved by RO.
> >
> >> check the integrity of the token and validate that it stems from AS
> >> that is authorized by RO.
> >
> >> Also, it would be helpful if the section also contained information
> >> how a server must react to missing fields, e.g., missing authenticity
> >> of the token or tokens from unknown authorization servers.
> >>
i.e.,
> which requirements a token must meet to be valid.
> 
> >
> > This should be covered in RFC 6749  and RFC 6819 which are referenced
> > in the security considerations.
> >
> >
> >> section 5.6.2 that the authorization rules that are presented to RS
> >> in the scope of the access token must reflect RO's decisions.
> >
describes
> that the authorization rules that the AS defines in the access token must
> reflect RO's decisions.
> 
> >
> >>
> >> (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 tokens.
> >
> > Thus the RS can adapt the number of tokens it stores to its
> > constrained storage resources.
> 

I don't think that it will mitigate the DoS attack.  What it will mitigate
is the memory resource exhaustion problem.  I would expect that something
along the lines of the "too many requests" error code would be used for a
DoS attack based on lots of requests.

> 
> >
> >> If introspection messages are used to check the validity of access
> >> tokens, the use of the authz-info resource amplifies the risk of DoS
> >> attacks since RS must send a message to its AS for every received
> >> token. These problems should be mentioned in the security
> >> considerations.
> >
> >> The preferred mitigation should be that the authz-info resource is
> >> only used for protected communication. This does obviously not work
> >> for the RPK mode. In the PSK mode, RS should be able to decide that
> >> it uses the authz-info resource only for protected updates.
> >
the
> token away immediately. Also, DTLS has some protection against DoS
> attacks. If a resource is used, clients can upload large numbers of tokens
to
> the resource, and no protection against DoS attacks is available. If the
> tokens are valid, the RS must in the worst case store them until they
expire,
> even if the client never tries to communicate with RS.

I am unaware of any DoS attacks that DTLS protects against that are not also
implementable for the resource.  This is esp. true with the newest "too many
requests" and "echo" drafts which are progressing.  What do you think you
have.  By the way if the server is forced to validate the token on every
connect then that will consume resources as well.  This is really true for
introspection.

Jim

> 
> >
> >> * How must the authz-info resource be protected? E.g., an attacker
> >> that is able to modify the resource may change or delete access
> >> tokens. The framework leaves the protection of the resource to the
> >> profiles, but I think some general advice can be offered by the
framework.
> >> It seems that the people who wrote the framework did not consider
> >> that the keying material is not only provided to RS but also to C.
> >> How does C determine if the keying material it receives from AS is
> >> still valid?
> >
> >> The access token response may comprise an expires_in field that
> >> contains the validity period of the access token in seconds (RFC
> >> 6749), but does not specify the validity period of the keying
the AS
> must check that the the keying material is valid at least as long as the
token
> and must then set the expires_in field to the remaining lifetime of the
token.
> Additionally, the AS should provide the time when the token was issued in
an
> iat field. A client that wants to communicate with an RS must check if the
> keying material it has for the RS is still valid.
> 
> >
> > should use a specific profile that defines additional mechanisms for
> > the client to check its tokens and associated keying material (e.g. by
> > using client introspection).
> >
> > of C accepts the AS in charge of RS. Otherwise the owner of C
> > shouldn't have configured C to communicate with RS in the first place.
> 
> >> IP addresses may change and therefore are not suitable. If AS
> >> specifies identifiers for RS, C must securely obtain this knowledge.
> >
> > Identifying the RS (using the audience claim and the req_aud
> > parameter) is application specific. Some applications may want to use
> > public keys, others will want to use fixed identifiers that are
> > manually assigned or otherwise generated.
> >
> >> The framework must point out that AS must check if the keying
> >> material that it provides to C in the access token response actually
> >> refers to the RS that C wants to communicate with. The problem of
> >> mixups concerning the RS must be mentioned in the security
> considerations.