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

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

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