Re: [tram] Contradictions in RFC8489

Nils Ohlmeier <nohlmeier@mozilla.com> Mon, 01 March 2021 23:01 UTC

Return-Path: <nohlmeier@mozilla.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 C7C6C3A2492 for <tram@ietfa.amsl.com>; Mon, 1 Mar 2021 15:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 IsJXs_B2aRAE for <tram@ietfa.amsl.com>; Mon, 1 Mar 2021 15:01:11 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 4049B3A247C for <tram@ietf.org>; Mon, 1 Mar 2021 15:00:40 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id e9so10859406plh.3 for <tram@ietf.org>; Mon, 01 Mar 2021 15:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cZGhpiV/NKw6lOlVP22xFLtOY74oIyRfi7KnJg9IVwY=; b=CiTq+G56OwAU40nup06WdLqZ/gwgVf5OdOAJKT7TOsGHxlP/rZ87y0dEKUelgH0QBW b8GMYnmHH+sYf+D1hzmHf8qSVf87Ka6gtlZDLlDQVR3nrbgVNcwHtpKZArRXki39FHGk qSMZqUaXna1FN9Pmuf2h2ERHMnu92gSiKAuYc=
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=cZGhpiV/NKw6lOlVP22xFLtOY74oIyRfi7KnJg9IVwY=; b=ih2YjukKeg1Av07UIKxs+fN5Kb/9IvuluyuOiVnC2qsNEUfJoU6qBQudkkv9LPLrfn SDAdOjVlNC0Aj8SOZl5GI89VuBgSaVGbJ4D4/lp0BCApcIphhT35nwdEKEjk9ekE+VXB LDeLtUSFRp4dnOAJNJaLZqtCW0HUCjvMxaIWK6GL5f1OI6nL43laZ7GXUolR006vK9jc AdvsBHnSgGFmatc72YJLf4PVGPtwvoSxqW7PDsltv/SXTDzHmDi30Tc9V2Zrr0ifRjiv zMT2B68ZUn6LL2VKnBp07olJZ+UJ1ZiHh2sD185rZKOjrwsQr0i7lrFaHBD3K6fL3RsG 85vA==
X-Gm-Message-State: AOAM531LTJXpfl14KEE19G65a4qdFczJuO9iZ5u6sR7TBVGyiZl2AYqX 7vH9QmuQ1M4afP64HpOUVkZs2w==
X-Google-Smtp-Source: ABdhPJz7CQLRWwBxItBZUOYijot7bbv12DUsNsgagkPIjBndaFaVnvkXh1ZaHbV1CXMfO8wG4Sq1iA==
X-Received: by 2002:a17:903:1d0:b029:df:d098:f1cb with SMTP id e16-20020a17090301d0b02900dfd098f1cbmr728962plh.49.1614639638711; Mon, 01 Mar 2021 15:00:38 -0800 (PST)
Received: from ?IPv6:2601:647:4600:3f31:107b:5b9b:e09d:d554? ([2601:647:4600:3f31:107b:5b9b:e09d:d554]) by smtp.gmail.com with ESMTPSA id m12sm474594pjk.47.2021.03.01.15.00.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 15:00:38 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Nils Ohlmeier <nohlmeier@mozilla.com>
In-Reply-To: <3710943A-50EC-42C5-B72D-5349B8C3FEE1@gmail.com>
Date: Mon, 01 Mar 2021 15:00:37 -0800
Cc: Karl Stahl <karl@ingate.com>, "tram@ietf.org" <tram@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA0F8033-C09C-48A2-9468-F522B649DC53@mozilla.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>
To: Dan Wing <danwing@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/pUi3R6feRxUsyucoUm-SpJQh2sg>
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:01:13 -0000

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 <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://tools.ietf.org/html/rfc8489#section-14.8 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://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
>> tram@ietf.org
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC
>