Subject: [tram] Contradictions in RFC8489

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 24 Feb 2021 15:58:42 -0800

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 25 Feb 2021 12:48:59 +0000

Nice catch!

Could it be that the use cases hinted at are some kind of anycast support where the anycast address redirects to a unicast address?

15<https://tools.ietf.org/html/rfc8489#section-15>.  Operational Considerations

   STUN MAY be used with anycast addresses, but only with UDP and in
   STUN Usages where authentication is not used.

Simon

On Feb 24, 2021, at 6:58 PM, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

When it comes to using the 300 responses with Alternate-Server attributes section 10 https://tools.ietf.org/html/rfc8489#section-10<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-10__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11MC7o-O3$> says:

But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-14.8__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11DOQq0dJ$> in regards to 300 responses says:

Best regards
  Nils Ohlmeier

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tram__;!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11Em3cMtH$

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 25 Feb 2021 16:11:56 +0000

Since I’m not on the TURN server side I don’t know about their reasons to
deploy their service without message integrity.
What I can say though is that the ICE of one browser accepts 300 responses
without message integrity. This might have influenced how services design
their server side systems.

Best
  Nils

Am 2/25/21 um 04:48 schrieb Simon Perreault <[email-masked]>:

 Nice catch!

Could it be that the use cases hinted at are some kind of anycast support
where the anycast address redirects to a unicast address?

15 <https://tools.ietf.org/html/rfc8489#section-15>.  Operational Considerations

Simon

On Feb 24, 2021, at 6:58 PM, Nils Ohlmeier <[email-masked]> wrote:

Hello,

When it comes to using the 300 responses with Alternate-Server attributes
section 10 https://tools.ietf.org/html/rfc8489#section-10
<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-10__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11MC7o-O3$>
 says:

But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8
<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-14.8__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11DOQq0dJ$>
in
regards to 300 responses says:

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.

Best regards
  Nils Ohlmeier

[email-masked]

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Feb 2021 11:36:35 -0800

> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <[email-masked]> wrote:
> 
> Hello,
> 
> When it comes to using the 300 responses with Alternate-Server attributes section 10 https://tools.ietf.org/html/rfc8489#section-10 says:
> 
> But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8 in regards to 300 responses says:
> 

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

> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC

---

From: Karl Stahl <[email-masked]>
Date: Sat, 27 Feb 2021 04:46:34 +0000

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]<mailto:[email-masked]>> wrote:

Hello,

-d

Best regards
  Nils Ohlmeier

---

From: Dan Wing <[email-masked]>
Date: Sat, 27 Feb 2021 17:49:20 -0800

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