Re: [tram] Contradictions in RFC8489

[Dan Wing <[e-mail]>]

> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <[e-mail]> wrote:
> 
> Hello,
> 
> I recently learned about an interesting contradiction in RFC 8489.
> 
> When it comes to using the 300 responses with Alternate-Server attributes section 10 https://tools.ietf.org/html/rfc8489#section-10 says:
> 
> The error response message MAY be
>    authenticated; however, there are use cases for ALTERNATE-SERVER
>    where authentication of the response is not possible or practical.
> 
> But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8 in regards to 300 responses says:
> 
> This error response MUST be protected with the
>         MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
>         receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
>         INTEGRITY-SHA256 of this response before redirecting themselves
>         to an alternate server.

There is some surrounding text of 14.8 which seems relevant, which I have bolded and marked with **,

   300  Try Alternate: The client should contact an alternate server for
        this request.  **This error response MUST only be sent if the
        request included either a USERNAME or USERHASH attribute and a
        valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute;
        otherwise, it MUST NOT be sent and error code 400 (Bad Request)
        is suggested**.  This error response MUST be protected with the
        MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
        receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
        INTEGRITY-SHA256 of this response before redirecting themselves
        to an alternate server.

        Note: Failure to generate and validate message integrity for a
        300 response allows an on-path attacker to falsify a 300
        response thus causing subsequent STUN messages to be sent to a
        victim.

I interpret the bolded sentence and the next sentence (starting with "This error ...") to mean: if the request arrived with USERNAME/USERHASH and valid MESSAGE-INTEGRITY(-256), then the response has to also contain MESSAGE-INTEGRITY(-256), else the response cannot be 300 Try Alternative (and recommends using response 400).

-d



> Looking at the previous RFC’s it looks like this contradiction has been in the STUN/TURN RFCs for a long time already.
> 
> I became aware of this problem, because it is causing interop issues between different stacks in the field.
> 
> I’m interested in the working the opinion of the TRAM experts on this topic.
> 
> Best regards
>   Nils Ohlmeier
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC