Preventing replay attacks in PUSH streams

[traib-google]

I may be misunderstanding some things so please correct me if required.

Background

While there's language that suggests Transmitter endpoints will be behind e.g. OAuth, today neither the SSF spec nor the CAEP Interoperability Profile talk about auth for Receiver (PUSH) endpoints.

Receiver endpoints are likely to be left open or use simple auth (e.g. API_KEY).

Since receivers are open, even signed SETs can be misused.

The Attack

AttackedReceiver creates a PUSH stream at the Transmitter, interested in subject S.
MaliciousReceiver creates another PUSH stream at the Transmitter, for the same subject S.

Transmitter sends event E to MaliciousReceiver.
MaliciousReceiver replays E to AttackedReceiver, which looks like it's coming from the Transmitter since it has all the right claims and is signed.

E.g. MaliciousReceiver can disrupt a customer by constantly sending session revoked events to the AttackedReceiver.

Prevention

The main idea is to ensure that an event is meant for a specific stream. Options:

• Add stream_id as a claim to the SET
• Include stream_id in the iss claim.
• Use stricter auth / OAuth, per-stream and per-Transmitter.

[FragLegs]

This is why it is necessary for the Receiver to check the aud claim in the SET. In your example, the SET sent to the malicious receiver would not have the correct aud value for the attacked receiver. So the attacked receiver should reject the SET when it arrives.

[FragLegs]

Also, when setting up push delivery, the receiver can set the authorization_header that the transmitter must include in every push. https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html#name-push-delivery-using-http

[traib-google]

You are right, I thought aud was Receiver-supplied but it's Transmitter-supplied. That plus the authorization_header should solve the problem.