Re: [Wish] Can a client switch tokens?

This is already covered on the security section:

Insecure direct object references (IDOR) on the WHIP session locations: If
the URLs returned by the WHIP endpoint for the WHIP sessions location are
easy to guess, it would be possible for an attacker to send multiple HTTP
DELETE requests and terminate all the WHIP sessions currently running. In
order to prevent this scenario, WHIP endpoints SHOULD generate URLs with
enough randomness, using a cryptographically secure pseudorandom number
generator following the best practices in Randomness Requirements for
Security [RFC4086], and implement a rate limit and avalanche control
mechanism for HTTP DELETE requests. The security considerations for
Universally Unique IDentifier (UUID) [RFC4122] Section 6 are applicable for
generating the WHIP sessions location URL.

You could restrict the http requests to the ip doing the initial http post
if you don't support ice restarts

Best regards
Sergio

El sáb, 13 ene 2024, 15:57, Juliusz Chroboczek <jch@irif.fr> escribió:

> Hi,
>
> Suppose I issue a token T1 to a client, and the client uses T1 to create
> a WHIP session.
>
>   C->S: POST(T1) offer
>   S->C: answer, Location: endpoint
>
> Suppose now that I issue a second token T2.  Is it legal for the client to
> use T2 with the endpoint that was created with token T1?
>
>   C->S: DELETE(T2) endpoint
>   S->C: 200 or 401?
>
> I can see pros and cons to both approaches.
>
> If we allow the token to change, then unless the endpoint URL is kept
> secret, a client might be able to destroy the session of a different
> client, instant DoS.
>
> If we don't allow the token to change, then we either need to ensure that
> tokens have a sufficient lifetime, or specify that the token used for
> creating a session may be used with that session even if it has expired.
>
> Galene currently does the following:
>
>   - it keeps the session URL secret;
>   - it enforces that the token used in PATCH/DELETE is the same as the one
>     that was used when creating the session;
>   - it allows the use of expired tokens in PATCH/DELETE (we simply compare
>     tokens, and ignore their properties at PATCH/DELETE time).
>
> I'm looking for implementation advice.  I'm not asking for normative
> language to be included in the draft (although an informative appendix
> might be helpful).
>
> Thanks,
>
> -- Juliusz
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>