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

[Rohan Mahy <[e-mail]>]

[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:).
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
>
>