Re: [tram] Contradictions in RFC8489

Dan Wing <danwing@gmail.com> Mon, 01 March 2021 23:09 UTC

Return-Path: <danwing@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FB03A249C for <tram@ietfa.amsl.com>; Mon, 1 Mar 2021 15:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx9lTRG9MRex for <tram@ietfa.amsl.com>; Mon, 1 Mar 2021 15:09:20 -0800 (PST)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257323A249B for <tram@ietf.org>; Mon, 1 Mar 2021 15:09:20 -0800 (PST)
Received: by mail-pf1-x431.google.com with SMTP id r5so12524996pfh.13 for <tram@ietf.org>; Mon, 01 Mar 2021 15:09:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l725wg6zZgj5QxypkuaezS2ee+dN6djH3I63V+Cq7Go=; b=NzMfQ0ZGYhxz0/E2xsap2ldvnOjAWtoY7cp1gTF+2sNRhaT5W84q47WqcTSrLhLAjq 5f972vdD6JAro4YUEAA2Kfurd7j3UMoMqji3UDPek1uFcEE91Ct8Me9dhsIAG9GFGUKe 0p7W8LLhwjiGwIsIN0UQ2FcIvxsEjRbOq8n9eXDXvLUCYnKFl154yt26toJpnWMkxjmV l5m+xhq0nwBhl2qqcjBlbKHZ2hTKDuHWBl/3ngkc6wQC3QzrMRvl5a6Rjmb9Ltl80/j0 c6ZZ90/MHIH8bZ1hgASH36Q9rHiog3ElSiOYEhTU5KJ6Kgm0H2KgTDZv7d7WHj0RkuFh RxIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l725wg6zZgj5QxypkuaezS2ee+dN6djH3I63V+Cq7Go=; b=L7QQEGfot+InAc98T+PEcva+9ecZAQkz8sZGAl4ztOdPyTGLRKg8yn76ykHSvlgsXc rkGtoeUcjhHowqwkeRJ0V1iDdAGBlHDSSneJv0PDDeddAoPXHeZC2py4EwNxXYhvAwls eal/yOqm0BXgdwZz6EyJ6DKTHZy9iRyyc7unqOd/fcRvrRkh7yqF2FOmsNPeZaMsqYNo HKVfWtq+eOkV540hApW3Uu5mNdSAn6DxuVoCTqPIfLP008bL55WvCXna4fyNq8AeaN3j Ka2ZwdY/Qc3+/vpYKWBeNn9aCiSRcJ2ie/DBmmEp11D2yLAgMxAgoMhaFeoLjcTSDssN xlTA==
X-Gm-Message-State: AOAM533ej+gQqGf/ghAmGihAOSHb13ep28nroAXwFdxCVqraO1RHlkJ8 ops4iw+fPVZ3YPi35Yd539/CRPn6fzA=
X-Google-Smtp-Source: ABdhPJyv5cNgF4Q6BBK6zarN+QAdd2ZeO6hw/nc8RRkDUiyZiMDd/sMqcpLpgiAhaEdrOLL1VmygeA==
X-Received: by 2002:a63:440d:: with SMTP id r13mr11616734pga.377.1614640158181; Mon, 01 Mar 2021 15:09:18 -0800 (PST)
Received: from [192.168.1.60] (47-208-190-34.trckcmtc01.res.dyn.suddenlink.net. [47.208.190.34]) by smtp.gmail.com with ESMTPSA id j20sm491817pjn.27.2021.03.01.15.09.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 15:09:17 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <EA0F8033-C09C-48A2-9468-F522B649DC53@mozilla.com>
Date: Mon, 01 Mar 2021 15:09:15 -0800
Cc: Karl Stahl <karl@ingate.com>, "tram@ietf.org" <tram@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A10ABDF3-EE6A-4803-949C-BDB689CD736B@gmail.com>
References: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com> <924F7C3A-B9A5-4648-ADC2-704EF78B8698@gmail.com> <VI1PR01MB3008208EA6E4C9B9BA674B1AB19C9@VI1PR01MB3008.eurprd01.prod.exchangelabs.com> <3710943A-50EC-42C5-B72D-5349B8C3FEE1@gmail.com> <EA0F8033-C09C-48A2-9468-F522B649DC53@mozilla.com>
To: Nils Ohlmeier <nohlmeier@mozilla.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/sOXyzSfWk_q3lvcUFpd4wPbddHw>
Subject: Re: [tram] Contradictions in RFC8489
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 23:09:22 -0000

On Mar 1, 2021, at 3:00 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
> 
> 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.

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


> 
> Best
>  Nils Ohlmeier
> 
>> On 27Feb, 2021, at 17:49, Dan Wing <danwing@gmail.com> 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 <karl@ingate.com> 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://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:
>>> 
>>> This error response MUST be protected
>>> 
>>> /Karl
>>> 
>>> Från: tram <tram-bounces@ietf.org> För Dan Wing
>>> Skickat: Friday, 26 February 2021 20:37
>>> Till: Nils Ohlmeier <nohlmeier@mozilla.com>
>>> Kopia: tram@ietf.org
>>> Ämne: Re: [tram] Contradictions in RFC8489
>>> 
>>> 
>>> 
>>> 
>>> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <nohlmeier@mozilla.com> 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://www.google.com/url?q=https://tools.ietf.org/html/rfc8489%23section-10&source=gmail-imap&ust=1615244441000000&usg=AOvVaw0-CXhLM0Njerpvm1lv0zKB 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://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:
>>> 
>>> 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
>>> tram@ietf.org
>>> 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