Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz <[e-mail]>]

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 [phone]