On 19/12/2018 12:46, Stefanie Gerdes wrote:
Hi Hannes,
On 12/19/2018 12:36 PM, Hannes Tschofenig wrote:
Hi Steffi,
Are you focused on token expiry or the case where a token + symmetric key has
been leaked?
I am talking about the expiry of the keying material for RS that AS
provides to C.
Is the threat you are describing the case where the client uses DTLS/TLS with
the RS (potentially long after a token has been presented), or the case where
the client contacts the RS and presents a token?
I am worried about cases where the client communicates securely with RS,
e.g., using DTLS/TLS or object security, not about presenting the token
to RS.
Viele Grüße
Steffi
The scenario Steffi is thinking of is this (if I understood correctly):
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.
A reasonable way to prevent this is to give the client a way to
determine whether a token has been revoked or is expired.
This former can be done through some form of client introspection, the
latter can be achieved with the expires_in parameter.
/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
