Subject: Re: [tram] Contradictions in RFC8489

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 1 Mar 2021 15:00:37 -0800

Hi Dan,

Thank you for that explanation. This is starting to make sense now for me.
So unauthenticated Alt-Server for Allocation requests are probably acceptable, as the turn client will have to go through authentication with the alt-server any way.
But receiving an unauthenticated 300 with alt-server while the turn client is already relaying data is a bad idea as you explained below.

This little, but important difference was not obvious from the RFC to me at all. I think it would be very helpful if this could get clarified in some way.

Best
  Nils Ohlmeier

> On 27Feb, 2021, at 17:49, Dan Wing <[email-masked]> wrote:
> 
> Alt-Server was contentious during standardization because an attacker can send legitimate traffic towards a victim -- much like an ICMP redirect (which is also unauthenticated).  The active discussions probably led to the contradictory text and, yet, implementations still need to do what they do.  Perhaps we need to refine text for an errata, or consider an updated RFC to clarify Alt-Server.
> 
> -d
> 
> 
>> On Feb 26, 2021, at 8:46 PM, Karl Stahl <[email-masked]> wrote:
>> 
>> Hi from Karl at Ingate & Intertex,
>> 
>> When used for auto discovery of a an enterprise turn server (on the LAN or in the access network), you typically don’t have any credentials and are talking clear text, but still get the 300 response, so there a non-authenticated 300 response must be allowed.
>> 
>> So this text is simply TOO STRICT and should be released:
>> 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
>> 
>> /Karl
>> 
>> Från: tram <[email-masked]> För Dan Wing
>> Skickat: Friday, 26 February 2021 20:37
>> Till: Nils Ohlmeier <[email-masked]>
>> Kopia: [email-masked]
>> Ämne: Re: [tram] Contradictions in RFC8489
>> 
>> 
>> 
>> 
>> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <[email-masked]> 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
>> [email-masked]
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Mar 2021 15:09:15 -0800

> But receiving an unauthenticated 300 with alt-server while the turn client is already relaying data is a bad idea as you explained below.

Yes, that's true.  But there is a risk with those un-authenticated Alt-Server responses generated by an on-path attacker:  the alt-server could be a victim, and thus legitimate TURN clients are going to flood a victim with TURN requests because of that un-authenticated Alt-Server response.  This turns TURN into a DoS vector.  The RFC's existing language guards against this.  

But it sounds like there is a deployment need to honor un-authenticated Alt-Server responses.  I'm not sure how to avoid being a DoS vector to a victim while also having the client process un-authenticated Alt-Server responses.  Perhaps forcing the client to be less aggressive with retries until it has authenticated with the Alt-Server?

> This little, but important difference was not obvious from the RFC to me at all. I think it would be very helpful if this could get clarified in some way.

Let's work on some text.

-d

>>> But then section 14.8 https://www.google.com/url?q=https://tools.ietf.org/html/rfc8489%23section-14.8&source=gmail-imap&ust=1615244441000000&usg=AOvVaw3NtZ6rOeegztcnSBlxtxdf in regards to 300 responses says:
>>> 
>>> When it comes to using the 300 responses with Alternate-Server attributes section 10 https://www.google.com/url?q=https://tools.ietf.org/html/rfc8489%23section-10&source=gmail-imap&ust=1615244441000000&usg=AOvVaw0-CXhLM0Njerpvm1lv0zKB says:
>>> 
>>> But then section 14.8 https://www.google.com/url?q=https://tools.ietf.org/html/rfc8489%23section-14.8&source=gmail-imap&ust=1615244441000000&usg=AOvVaw3NtZ6rOeegztcnSBlxtxdf in regards to 300 responses says:
>>> 
>>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/tram%26source%3Dgmail-imap%26ust%3D1614815933000000%26usg%3DAOvVaw1n1YAlhUsnhlTcx1V3NGXC&source=gmail-imap&ust=1615244441000000&usg=AOvVaw0BLl1MdAqskZOLtS2OHRNf