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

[Rohan Mahy <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]>
> > 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: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>