On 19/12/2018 21:22, Jim Schaad wrote:
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.
I am having a real problem with the idea that we are going to start
adding the idea of revocation to the entire system. I would much
rather make sure that both sides are given an idea of when things are
going to expire and just make things expire relatively quickly.
It's quite unlike the revocation in PKI, it's just that an AS can mark a
token as invalid, and this information would then be available to those
who can do introspection.
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.
This depends on the version of PSK that you are doing. If you use
PSK+ECDH then the attacker cannot hijack the connection.
Right of course. I suspect however that not all constrained devices
would implement the PSK+ECDH handshake, or are the other PSK handshakes
deprecated?
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.
It would be more reasonable to say that if you are doing a physical
attack, then it would be easy to get an RPK and then you are the RS
until such a time as the AS is told that the key is no longer
trusted. In this case you will just continue getting tokens as a
client which are still valid and none of this is helpful in any
event.
Ok my example was perhaps not ideal, since it has an even bigger breach
as precondition. So under what conditions would an attacker get access
to a pop-key of an expired token? Steffi any ideas?
/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
