Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Rohan Mahy <rohan.mahy@gmail.com> Sun, 07 October 2018 20:37 UTC

Return-Path: <rohan.mahy@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 591AF130DEF; Sun, 7 Oct 2018 13:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b_GDJ6h2iVYk; Sun, 7 Oct 2018 13:37:21 -0700 (PDT)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 0C62F124D68; Sun, 7 Oct 2018 13:37:21 -0700 (PDT)
Received: by mail-ua1-x92b.google.com with SMTP id g18-v6so6459585uam.6; Sun, 07 Oct 2018 13:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Zhw2ip7iPwAsN+7vVKl362nVGD6b0/zAOUQq9AvHJw=; b=Kf5rlbOrKCAX2u8175/O0DtyJkOr3oGbq9nO02uDzRmxa223ul8ullFfLexKhojCMw jjDN7+/l/P+w9kxjc305QbCcc3oTsosnojlOQx3urDpkEr74g5R7oz15W19JQJuXVUtc ClsWHJUZrk2uZymvQdYVYJ+eB3zl2kZVPI3hHibuYjTCLCHIE/uFhXEaJyyb0QDYsU4V SAuOovP6NFrzonvoZU1662MXhz+Fl2phmhzrKvoI7JiPzrqCPjU+Fpu4fPxbIGj1BJwj w/4/VQDXYzLwlL6hn+qMYRZPD6T3QDj0RW9l5FLQ3QhgLZXZF302rnz9Tcq8KWzM2Yj2 AgMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Zhw2ip7iPwAsN+7vVKl362nVGD6b0/zAOUQq9AvHJw=; b=IG+JFEek7icRqq3x3OsSaOJCQDAj/adz+hanKDsaFJTQ7KiQsIJS3ONEjC4ihdHqeh 187eKhoEMwFpFIBHxs6YDQMWnUiXfiTfDXkPpWcFUlSM2DlsbS65N7i4aUVMy/V91apy yPXHTedFHM03pz8VY44UwctEiDHdjHzdPJG8EQjJEn3hj7J9aLlYsxggObKACRO6Jz1y rP5n/EvWWsmZmA0a2z0UF2+Ruz3YzcgGvJmE0Pu/arDrszDkgFm7jSjup3Xe/RTWy4iV /h5hzvYgN1TB0aoGjjzv4XDCHRJW7msDPPD/rbkiuAYciLDUR6mqs1NgLBNn4s+uMspP CGHg==
X-Gm-Message-State: ABuFfoi4o/GeJ4XGTcyBzcQA6Hn1jpUX9XN1AAF2bxoxXK0FrkBBVU5I wLU9z45slG3sMvYINggdazN8HXUrDKcMI1KjIhc=
X-Google-Smtp-Source: ACcGV605yRjmCf2DOvOEH8SfMb803Bb4bqPWrbis+y3F704K0o3IGzKb/XEVMJZA12VHZfyj+WAAanUd4I8Cgoia+4g=
X-Received: by 2002:ab0:2101:: with SMTP id d1mr7732463ual.108.1538944639836; Sun, 07 Oct 2018 13:37:19 -0700 (PDT)
MIME-Version: 1.0
References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <df27ff82-bb5a-8c83-f119-a6f4e9f65a53@nostrum.com> <a5da7dc3-472c-8dcf-27e0-7e334d6590f6@ericsson.com> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <b845eb08-7974-ec9d-0a98-e04d6071b2e1@petit-huguenin.org> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> <CAKoiRuacSP_FuXouxfSbbZ5fN_9O1gxBPwUomranS_Cz5YawMA@mail.gmail.com> <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org>
In-Reply-To: <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Sun, 7 Oct 2018 13:37:08 -0700
Message-ID: <CAKoiRub8vo+X419QgbiyvQKUoc4nGJdKfEJTM+CUGKpV_7x-rA@mail.gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Adam Roach <adam@nostrum.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, The IESG <iesg@ietf.org>, tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren <tasveren@rbbn.com>, tram@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009628650577a978bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/wyGvsmQmUAz0Ok4tpNQtslI2FcU>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
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: Sun, 07 Oct 2018 20:37:25 -0000

If we think this might happen we could add: "A future STUN extension or
usage may relax this requirement provided it demonstrates how to
authenticate the STUN server and prevent man in the middle attacks."
Thanks,
-rohan

On Sun, Oct 7, 2018, 08:17 Marc Petit-Huguenin <marc@petit-huguenin.org>
wrote:

> On 10/07/2018 08:05 AM, Rohan Mahy wrote:
> > [snip]
> >>> using https, that the hostname verification for the https certificate
> >>> implies that the stuns URI embedded in the document are receiving
> >>> adequate protection and can be used without worrying about the lack of
> >>> certificate verification for the stuns URI.
> >>>
> >>> Now that is an assumption that we made, and we'd very much like to hear
> >>> if that assumption is incorrect.
> >>
> >> Note that I may be lacking full context, but based just on your
> > description
> >> above and § 8.1 of the -18, I am concerned about your statement "without
> >> worrying about the lack of certificate verification for the stuns URI".
> > My
> >> understanding is, that given a stuns URI with an IP address for the host
> >> and some domain name specified by the same mechanism that provided the
> > URI,
> >> is that this domain name would then be used as input to the servername
> >> verification process for the new connection using this stuns URI.  Your
> >> statement that I quote here makes it sound like no certificate
> > verification
> >> is done on this second connection, which would seem to make it
> vulnerable
> >> to a MITM attack (and thus be a bad idea).
> >
> > Probably too late now, but if you wanted to be able use a stuns: URI
> safely
> > with an IP address, you could use a fingerprint URI parameter to prevent
> > MITM. This would work as long as you received the URI over an
> authenticated
> > channel (ex: https:, sip: + S/MIME, and possibly sips:).
>
> Yes but, as you said, it is too late now for stunbis and TRAM.  Maybe in a
> draft in 2019...
>
> > Thanks,
> > -rohan
> >
> > On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin <
> marc@petit-huguenin.org>
> > wrote:
> >
> >> Hi Benjamin,
> >>
> >> See inline.
> >>
> >> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote:
> >>> Hi Marc,
> >>>
> >>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote:
> >>>> Hi Adam,
> >>>>
> >>>> Apologies for the delay in working on that.
> >>>>
> >>>> For the first issue, the fix is in my copy of the draft.
> >>>>
> >>>> As for the second issue, Section 8.1 says:
> >>>>
> >>>> 'A "stuns" URI
> >>>>  containing an IP address MUST be rejected, unless the domain name is
> >>>>  provided by the same mechanism that provided the STUN URI, and that
> >>>>  domain name can be passed to the verification code.'
> >>>>
> >>>> That text was never about IP addresses in certificates, but about the
> >> way a STUN (or TURN really, but that draft does not care about TURN)
> server
> >> IP address is passed to a WebRTC browser.  RFC 7064 permits to store an
> IP
> >> address directly inside a stun URI, and RFC 7350 extended that to stuns
> >> URI, and in fact the text above is directly copied from RFC 7350.
> >>>>
> >>>> The idea is that a stun URI can be provisioned by a JavaScript program
> >>>> downloaded by a WebRTC browser as part of the initialization of a
> WebRTC
> >>>> application.  A security assumption is that using a stuns URI that
> >>>> contains an API address is safe if the Javascript program was
> downloaded
> >>>               ^^^
> >>> (I assume this is autocorrect picking the wrong thing to fix a typo and
> >>> should be "IP Address")
> >>
> >> Yes.  But no auto-correct feature was to blame in that case.
> >>
> >>>
> >>>> using https, that the hostname verification for the https certificate
> >>>> implies that the stuns URI embedded in the document are receiving
> >>>> adequate protection and can be used without worrying about the lack of
> >>>> certificate verification for the stuns URI.
> >>>>
> >>>> Now that is an assumption that we made, and we'd very much like to
> hear
> >>>> if that assumption is incorrect.
> >>>
> >>> Note that I may be lacking full context, but based just on your
> >> description
> >>> above and § 8.1 of the -18, I am concerned about your statement
> "without
> >>> worrying about the lack of certificate verification for the stuns URI".
> >> My
> >>> understanding is, that given a stuns URI with an IP address for the
> host
> >>> and some domain name specified by the same mechanism that provided the
> >> URI,
> >>> is that this domain name would then be used as input to the servername
> >>> verification process for the new connection using this stuns URI.  Your
> >>> statement that I quote here makes it sound like no certificate
> >> verification
> >>> is done on this second connection, which would seem to make it
> vulnerable
> >>> to a MITM attack (and thus be a bad idea).
> >>
> >> You are right.  I am not sure if there is an easy way to fix that but if
> >> someone figure that out it can be spelled out in a separate draft.
> >> Meanwhile I updated the text in the new version of the draft as follow:
> >>
> >> "If the <host> part of a "stun" URI contains an IP address, then this
> >>  IP address is used directly to contact the server.  A "stuns" URI
> >>  containing an IP address MUST be rejected."
> >>
> >>>
> >>> -Benjamin
> >>>
> >>>> Section 6.2.3 is unrelated - it is about IP addresses provisioned
> >> locally (not received from the server), and a matching certificate
> >> containing IPAddress.  I'll make that more explicit after I receive your
> >> response on the subject above.
> >>>>
> >>>> Also it seems that your DISCUSS is not related to that issue at all,
> >> would it be possible to clear it?
> >>>>
> >>>> Thanks.
> >>>>
> >>>> On 06/18/2018 10:45 AM, Adam Roach wrote:
> >>>>> Gonzalo:
> >>>>>
> >>>>> TL;DR -- unless someone can find evidence indicating what the WG
> >> intended, I believe we are waiting on you and Simon.
> >>>>>
> >>>>> I had two responses in my most recent message. I presume the first
> >> should be uncontroversial.
> >>>>>
> >>>>> The second point pertains to how the working group intended to treat
> >> IP addresses in STUNS URIs. The document right now is ambiguous and
> >> self-contradictory. If this has been discussed in the past, then the
> >> document simply needs to be updated to reflect the outcome of that
> >> conversation. If not, then I believe the WG needs to have a conversation
> >> about what is intended.
> >>>>>
> >>>>> As it stands, the document will lead to various notions about whether
> >> (and how) IP addresses can be used, which will be an interop nightmare.
> >>>>>
> >>>>> /a
> >>>>>
> >>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote:
> >>>>>> Marc, Adam,
> >>>>>>
> >>>>>> what is the status of this discussion?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Gonzalo
> >>>>>>
> >>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote:
> >>>>>>> Sorry for taking so long to get back to you on this. Two responses
> >> below
> >>>>>>> -- everything else looks good.
> >>>>>>>
> >>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:
> >>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote:
> >>>>>>>>>>
> >>
> ---------------------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> §17.3.1:
> >>>>>>>>>>
> >>>>>>>>>>>    IANA is requested to update the names for attributes 0x0002,
> >> 0x0003,
> >>>>>>>>>>>    0x0004, 0x0005, 0x0007, and 0x000B, and the reference from
> >> RFC 5389
> >>>>>>>>>>>    to RFC-to-be for the following STUN methods:
> >>>>>>>>>> ...
> >>>>>>>>>>>    0x0003: (Reserved; prior to [RFC5389] this was
> CHANGE-REQUEST)
> >>>>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not
> be
> >>>>>>>>>> removed by this document.
> >>>>>>>>> Fixed.
> >>>>>>>
> >>>>>>> Thanks for the change, but the new text still asks IANA to update
> the
> >>>>>>> table so that 0x0003 points to *this* document, instead of
> >> continuing to
> >>>>>>> point to RFC 5780. Since this document does not do anything with
> >>>>>>> CHANGE-REQUEST, this update does not seem correct.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>
> ---------------------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> §6.2.3 says:
> >>>>>>>>>>
> >>>>>>>>>>>    Alternatively, a
> >>>>>>>>>>>    client MAY be configured with a set of IP addresses that are
> >>>>>>>>>>> trusted;
> >>>>>>>>>>>    if a certificate is received that identifies one of those IP
> >>>>>>>>>>>    addresses, the client considers the identity of the server
> to
> >> be
> >>>>>>>>>>>    verified.
> >>>>>>>>>> Presumably, this means the server supplies a certificate with
> >>>>>>>>>> SubjectAltName
> >>>>>>>>>> containing an iPAddress? Please add text to clarify whether
> >> that's the
> >>>>>>>>>> intention.
> >>>>>>>>>>
> >>>>>>>>>> If that *is* the intended meaning, then this behavior in §8.1
> >> seems
> >>>>>>>>>> unnecessarily restrictive:
> >>>>>>>>>>
> >>>>>>>>>>>    A "stuns" URI
> >>>>>>>>>>>    containing an IP address MUST be rejected, unless the domain
> >> name is
> >>>>>>>>>>>    provided by the same mechanism that provided the STUN URI,
> >> and that
> >>>>>>>>>>>    domain name can be passed to the verification code.
> >>>>>>>>>> Presumably, this is done because certs with iPAddress-form
> >>>>>>>>>> SubjectAltNames are
> >>>>>>>>>> pretty rare (although CAB Forum baseline requirements do
> >> explicitly
> >>>>>>>>>> allow
> >>>>>>>>>> their issuance) -- but if the text in §6.2.3 is based on
> allowing
> >>>>>>>>>> the use of
> >>>>>>>>>> such certs in a TURN deployment, then it seems that URI
> resolution
> >>>>>>>>>> should be
> >>>>>>>>>> also.
> >>>>>>>>>>
> >>>>>>>>> I am not sure what was the intent there, so I'll work on that
> >> later.
> >>>>>>>> We addressed all the other comments, but it would be great if you
> >>>>>>>> could suggest some text to address that one.
> >>>>>>> I'm not sure what was meant either!
> >>>>>>>
> >>>>>>> I think we need to untangle what the working group meant to say
> >>>>>>> regarding "trusted IP addresses," the way this protocol is intended
> >> to
> >>>>>>> use certs, and whether the prohibition on using IP addresses in
> >> "stuns"
> >>>>>>> URIs derives from cert handling or if it has a completely different
> >>>>>>> rationale behind it; and, if the former, ensure that those things
> >> that
> >>>>>>> are prohibited or allowed in certs are similarly prohibited or
> >> allowed
> >>>>>>> in URIs.
> >>>>>>>
> >>>>>>> I can suggest some *behavior*, but unless there is some record of
> >> what
> >>>>>>> the WG meant, any such behavior would need to be discussed by the
> >>>>>>> working group, and a consensus would need to be declared by the
> >> chairs.
> >>>>>>>
> >>>>>>>
> >>>>>>> /a
> >>>>>>>
> >>>>>
>
>
>
> --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>