Re: [Ace] ACE Framework Review
On 12/11/2018 15:31, Michael Richardson wrote: > 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. 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ACE Framework Review
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 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 [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ACE Framework Review
> -Original Message- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, October 22, 2018 6:08 AM > To: ace@ietf.org > Subject: Re: [Ace] ACE Framework Review > > On 10/10/2018 16:24, Stefanie Gerdes wrote: > > 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). > > 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 > > > 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. 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). > > > 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". Additionally one could use the clear everything after n accesses to resources. > > 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. 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. > > 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. 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. > > 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
Re: [Ace] ACE Framework Review
On 10/10/2018 16:24, Stefanie Gerdes wrote: 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). 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 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. Agree. I will add a paragraph. 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. 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. 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. 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". 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." Also, it would be helpful if the section
