Re: [Ace] ACE Framework Review

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Stefanie Gerdes
> Sent: Wednesday, October 24, 2018 6:53 AM
> To: Ludwig Seitz <[e-mail]>; [e-mail]
> Subject: Re: [Ace] ACE Framework Review
> 
> Hi Ludwig,
> 
> On 10/22/2018 03:07 PM, Ludwig Seitz 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 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.
> 
> 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.

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.
> 
> 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 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.
> >>
> >
> > 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.
> 
> 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.
> 
> >
> >> 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).
> >
> > 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 approach is particularly vulnerable to DoS attacks
> >> since 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.
> 
> It might be useful to mention that 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.
> >>
> > 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".
> 
> 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.

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.
> >
> > 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.
> >
> >>
> >> 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.
> >
> > We can expand on this phrase I think: "The RS receiving the token MUST
> > verify the validity of the token."
> 
> That sounds like a good idea.
> 
> >
> >
> >> 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.
> >>
> > 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)."
> 
> 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.
> 
> >
> >> 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.
> >>
> > This should be covered in RFC 6749  and RFC 6819 which are referenced
> > in the security considerations.
> >
> >
> >> 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.
> >
> > 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.
> 
> >
> >>
> >> 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.
> >
> > 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.
> 
> I don't really understand how storing at least one access token helps to
> mitigate the problem of DoS attacks.

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.
> >
> > I will add a section describing the problem.
> >
> >
> >> 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.
> >
> > 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.
> 
> 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.

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.
> >
> > I can add a paragraph on this in section 5.
> >
> >>
> >> 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?
> >
> > 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 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.
> >>
> >
> > 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.
> 
> 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.
> 
> >
> > 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).
> >
> >> The framework should also mention that C must determine if AS is
> >> 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.
> 
> And how does C know that a certain AS is in charge of RS?
> 
> >
> >> 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.
> >
> > 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.
> >
> >> 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.
> >>
> >
> > I will add a paragraph describing the problem and giving some basic
> > suggestions (such as public keys as identifiers).
> >
> >
> >> 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.
> >
> > I can add a sentence about this, although it seems very obvious.
> >
> > /Ludwig
> >
> >
> 
> Viele Grüße
> Steffi
> 
> --
> Stefanie Gerdes			Tel: [phone]
> TZI Universität Bremen		E-Mail: [e-mail]
> Bibliothekstr. 1, MZH 5150
> 28359 Bremen, Germany
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace