> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Wednesday, December 19, 2018 5:24 AM
> To: Hannes Tschofenig <[email protected]>; Stefanie Gerdes
> <[email protected]>; Jim Schaad <[email protected]>; [email protected]
> 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.
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.
>
> > 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.
>
>
> > 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.
Jim
>
> >
> > 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
