Subject: [tram] Open issue #4: domain/ip address handling in stun-dtls

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 06 Mar 2014 05:55:41 -0800

Following the discussion yesterday in the TRAM session about the domain/ip
address handling for STUN over DTLS, we discussed what to do in the draft, and
came with an alternate solution that could be better than the conclusion in
the session (which was to forbid IP addresses).  Because IP addresses are
already accepted when TLS will be used with a STUN/TURN URI, that would
require a document modifying 7064/65 to change that also for DTLS.

As a reminder, here's the text in RFC 5389:

  "The client
   MUST verify the identity of the server.  To do that, it follows the
   identification procedures defined in Section 3.1 of RFC 2818
   [RFC2818].  Those procedures assume the client is dereferencing a
   URI.  For purposes of usage with this specification, the client
   treats the domain name or IP address used in Section 8.1 as the host
   portion of the URI that has been dereferenced.  Alternatively, a
   client MAY be configured with a set of domains or IP addresses that
   are trusted; if a certificate is received that identifies one of
   those domains or IP addresses, the client considers the identity of
   the server to be verified."

The problem here is when the IP address has been resolved before the URI was
created, which will be the case most of the time in the WebRTC server.  What
we would suggest is to to add a new member in the RTCIceServer dictionary to
carry the domain name (names?) to validate in case IP addresses are used in
the STUN/TURN URI (pretty much like what was done for the username and password).

Comments?

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug