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