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

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 7 Oct 2018 05:47:54 -0700

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 7 Oct 2018 05:53:48 -0700

Hi Adam,

See one more response inline.

Additionally it seems that your DISCUSS is not related to these issues at all, would it be possible to clear it?

Thanks.

On 05/21/2018 11:11 AM, Adam Roach wrote:
> Sorry for taking so long to get back to you on this. Two responses below -- everything else looks good.
> 
>>>> 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.
> 
> 
>>>>>   client MAY be configured with a set of IP addresses that are trusted;
>>>> Presumably, this means the server supplies a certificate with SubjectAltName

To align with the modification done in section 8.1. (see my previous email to Benjamin Kaduk), I completely removed the sentence from the next version of the draft.

>>>> 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.
>>>>
>> We addressed all the other comments, but it would be great if you could suggest some text to address that one.
> 
> 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
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 7 Oct 2018 08:05:36 -0700

[snip]
> 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 <[email-masked]>
wrote:

> >> 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.
> >>
> 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:
>
> >> 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.
> >>
> >>> TL;DR -- unless someone can find evidence indicating what the WG
> intended, I believe we are waiting on you and Simon.
> >>>
> >>> 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
> >>>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 7 Oct 2018 08:17:09 -0700

> 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...

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Oct 2018 15:27:19 -0500

Hi Marc,

>  containing an IP address MUST be rejected."

Thanks, this is an okay way to address my concern.  (I think it would also
be fine to allow "stuns" URIs with IP addresses, if they are obtained over
secure transport and accompanied by a hostname to use in certificate
validation, but I can understand if you don't want to try to capture the
subtleties of that in a document at this stage of processing.)

-Benjamin

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 7 Oct 2018 13:37:08 -0700

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 <[email-masked]>
wrote:

> >>>>>>>>>>>    addresses, the client considers the identity of the server
> to
> >> be
> >>>>>>>>>>>    verified.

---

From: Adam Roach <[email-masked]>
Date: Tue, 9 Oct 2018 12:30:31 -0500

> Also it seems that your DISCUSS is not related to that issue at all, would it be possible to clear it?

Yes -- I've cleared the DISCUSS.

/a

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 15 Oct 2018 05:22:09 -0700

Hi Rohan,

Thanks, I added your text verbatim to the end of the first paragraph of section 8.1.

I will publish -19 in few minutes.