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

[Hannes Tschofenig <[e-mail]>]

Hi Ludwig, Hi Jim

A few remarks below:

-----Original Message-----
From: Ludwig Seitz <[e-mail]>
Sent: Donnerstag, 20. Dezember 2018 08:40
To: Jim Schaad <[e-mail]>; Hannes Tschofenig <[e-mail]>; 'Stefanie Gerdes' <[e-mail]>; [e-mail]
Subject: Re: [Ace] Security of the Communication Between C and RS

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.

[Hannes] I see revocation and expiry of credentials as two somewhat different concepts.
In OAuth, we have a spec that deals with a limited form of revocation but the best mitigation IMHO is to issue "short-lived" tokens (short lived in the context of the given application domain). The token introspection interface also provides additional capabilities for real-time checking the status of a token. Finally, it is worth mentioning the SecEvents work here as well.

In practice it is difficult to revoke tokens in a timely fashion since you have to find out that there has been a leakage in the first place, which (as media reports indicate) often takes months if not years for companies to notice.

Regarding expiry of the token, we have the ability for the AS to tell the client as well as the RS how long the token is valid. Do we want to mandate it? Even if I don't see the harm in not providing the info to the client I am saying "why not". I am just not sure whether mandatorily sending the expired_in parameter to the client will help to prevent any attacks.

>>
>>> 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?

[Hannes] It really depends what assumptions you make about how the attacker managed to get access to the PoP key in the first place, which we haven't really gone into any level of detail.
From my experience (as I mentioned to John  Mattsson in his DTLS/TLS vs. OSCORE performance analysis) use of PSK+ECDH(E) is rather unlikely since you are essentially dumping the positive effects of the PSK-based mechanism while maintaining all the negative aspects of the long-term PSK credential.

>>
>>> 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?

[Hannes] We definitely need some more details about the type of attack we would like to prevent. Maybe it is worthwhile to think about what information the attacker steals from whom at what point in time could be a way to progress the topic.

Ciao
Hannes


/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.