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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
