Hello, >> If it is detected the AS would revoke the token. Then the client _could_ use >> client introspection to get that information. Note that this is what the CMU >> people are looking at.
Yes, handling compromised RSs is in fact something that we have been looking into. Our main concern is that in our scenarios, the environment is expected to be very hostile and connection is limited and intermittent (disadvantaged or DIL networks). Since we wanted to add some support for revoking tokens, without having to modify the framework to handle token revocation explicitly, what we ended up doing was using client introspection, along with some caveats and some considerations, to be able to add this functionality, besides also having ways to handle expired tokens. The main advantage of this is, again, that we aren't really modifying or even extending the ACE framework, but just taking advantage of functionality that is already there to implement this functionality, which makes sense in our use case. In fact, we were looking into writing a BCP-like document suggesting ways to do this based on what we did. We were envisioning this as maybe the starting point of a document containing practices on how to better handle client communications with OAuth/ACE when we are dealing with disadvantaged networks and hostile environments. If there is interest in the group, we could share that document here, and maybe discuss what other practices could be added to it. Thanks, --- Sebastian Echeverria Tactical Technologies Group (TTG) Software Engineering Institute Carnegie Mellon University -----Original Message----- From: Ludwig Seitz [mailto:ludwig.se...@ri.se] Sent: Wednesday, December 19, 2018 8:24 AM To: Hannes Tschofenig <hannes.tschofe...@arm.com>; Stefanie Gerdes <ger...@tzi.de>; Jim Schaad <i...@augustcellars.com>; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS On 19/12/2018 14:04, Hannes Tschofenig wrote: > Thanks, Ludwig. The list of steps below help me to understand the concern. > > ---- > > > 1.) C obtains token and pop-key from AS > 2.) C transmits token to RS and sets up secure communication (e.g. > DTLS-PSK) using the pop-key > 3.) C sends secure requests to the RS > 4.) token expires, an attacker manages to get hold of the pop-key > 5.) C continues to send requests containing sensitive information to the RS , > attacker can now read the messages and spoof positive responses from the RS. > C never notices that the token is invalid and that it is actually talking to > the attacker. > > ---- > > In step (4) you tie the expiry of the token to the attacker getting > hold of the key. What happens if the attacker gets hold of the pop key > before the token expires? If it is detected the AS would revoke the token. Then the client _could_ use client introspection to get that information. Note that this is what the CMU people are looking at. > Additionally, if you use DTLS/TLS just having the PoP key still > requires the attacker to run a new DTLS/TLS handshake with the RS. If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker should be able to hijack the connection and impersonate either party. > It would also be useful to know where the attacker got the PoP key > from and how you can even detect the compromise. That is a different story entirely. You could imagine the case of an RS improperly deleting an expired token and the associated pop-key, and then being subject to a physical attack that recovers that information. > > Additionally, there is the question why the RS wouldn't stop > communicating if the token expired since it has that information. The RS would indeed stop, but since the token is opaque to the client, it has no way of knowing that the token has expired, and our clever attacker is using the pop-key to impersonate the RS and maintain the illusion that the connection is still alive an running. > Normally, the idea is that the RS has a protected resource and the > client wants to access it. That's why the RS is asking the client to > send a token that gives it access. > Yes but say e.g. that the RS is a message broker and the client is a publisher, writing sensitive data to the RS. I think Steffi's point definitely warrants text in the security considerations, outlining how a client could detect that a token has expired. /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
