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

[Marc Petit-Huguenin <[e-mail]>]

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