One document matched: draft-ietf-tram-stun-origin-05.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tram-stun-origin-05" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="STUN Origin">An Origin Attribute for the STUN Protocol</title>

    <author fullname="Alan Johnston" initials="A."
            surname="Johnston">
      <organization>Avaya</organization>

      <address>
        <postal>
          <street></street>

          <city>St. Louis</city>

          <region>MO</region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>alan.b.johnston@gmail.com</email>

      </address>
    </author>

    <author fullname="Justin Uberti" initials="J."
            surname="Uberti">
      <organization>Google</organization>

      <address>
        <postal>
          <street></street>

          <city>Kirkland</city>

          <region>WA</region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>justin@uberti.name</email>

      </address>
    </author>

    <author fullname="John Yoakum" initials="J."
            surname="Yoakum">
      <organization>Avaya</organization>

      <address>
        <postal>
          <street></street>

          <city>Cary</city>

          <region>NC</region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>yoakum@avaya.com</email>

      </address>
    </author>

    <author fullname="Kundan Singh" initials="K."
            surname="Singh">
      <organization>Avaya</organization>

      <address>
        <postal>
          <street></street>

          <city>San Francisco</city>

          <region>CA</region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>kundan10@gmail.com</email>

      </address>
    </author>

    <date year="2015" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
         in the current day and month for you. If the year is not the current one, it is
         necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
         purpose of calculating the expiry date).  With drafts it is normally sufficient to
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>RAI</area>

    <workgroup>TRAM Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>turn</keyword>
    <keyword>webrtc</keyword>
    <keyword>rtcweb</keyword>
    <keyword>origin</keyword>
    <keyword>attribute</keyword>
    <keyword>stun</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs.  This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name.  WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive.  This specification defines the usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
<t>
STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs.  TURN, or Traversal Using Relays around NAT <xref target="RFC5766" />, is a STUN extension <xref target="RFC5389" /> that allows endpoints to acquire a relayed address for media flows.  It is most commonly used in conjunction with ICE, Interactive Connectivity Establishment <xref target="RFC5245" />, which is used to establish peer-to-peer flows between endpoints through NATs and firewalls.
</t>
<t>STUN defines three authentication modes, depending on the STUN usage.  For STUN binding requests sent between peers, such as for ICE connectivity checks, a short term authentication method is recommended.  Each peer contributes random strings which are exchanged over signaling and used to authenticate the connectivity checks.  For TURN, a usage of STUN used to acquire and refresh relay addresses, a long term authentication method is recommended.  This authentication is similar to SIP Digest <xref target="RFC3261" />, which involves an authentication challenge for each request.  A server, upon receipt of a TURN request, generates an authentication challenge that includes a realm and nonce.  The client resends the TURN request supplying a user name and password based on the realm indicated by the server.  For a STUN binding request sent to a STUN server, no authentication is recommended, as generating the response is less work for a server than the server utilizing the short term or long term authentication approach.  The server responds statelessly, so the only resources used are those to process each request, which are minimal.
</t>
<t>
WebRTC, Web Real-Time Communications, adds peer-to-peer real-time, interactive voice and video media capabilities and data channels to browsers <xref target="I-D.ietf-rtcweb-overview" /> without a plugin or download, and allows web developers to access this functionality using JavaScript API calls <xref target="WebRTC-API" />.  WebRTC includes STUN, TURN, and ICE client functionality built into browsers.  For a session established between two browsers, if either browser is behind a NAT, a STUN server is necessary.  Public STUN servers are currently available and a web application can suggest a particular STUN server be used.  In cases where a particular combination of NAT mapping and filtering and/or firewalling is present, a TURN server is needed to establish a peer connection.  In this case, TURN credentials need to be available to the browser for the long term authentication approach.  A TURN server for WebRTC might serve a number of different domains and realms.
 </t>
 <t>
From the perspective of the web application provider, providing service for a number of different domains and realms, it is useful to know something about the source of the STUN request when processing the request.  For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service.  In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application.  For a web application provider TURN server, the TURN server does not know which realm to include in an authentication challenge. 
</t>
<t>
In the web world, HTTP requests have the concept of origin.  The origin of a web page, as defined in <xref target="RFC6454" />, is defined by the URI's scheme, host or IP address, and port portions.   The HTTP Origin header field inserted by the web browser carries this information and is useful information for servers that receive HTTP requests generated via JavaScript.  For example, Cross Origin Resource Sharing, CORS, allows an HTTP server to serve HTTP requests from multiple origins. 
</t>
<t>
This specification proposes extending the origin concept to STUN requests.  STUN requests generated by a web browser would include the origin of the HTTP page that is initiating the Peer Connection.  Using this extra information, a STUN server could use the origin to determine which STUN binding requests to respond to, reducing the load on a STUN server.  Using this  information, a TURN server could use the origin to determine which realm to include in the authentication challenge. A TURN server can also use the origin information for logging and analytics, and also as additional information after authentication for providing service.   This specification also defines an origin for SIP and XMPP users of STUN and TURN.
</t>
<t>
An important use case that the STUN Origin helps solve is the operation of a multi-tenanted TURN server (i.e. a TURN server that serves multiple, perhaps tens of thousands of different domains).  The problem associated with this use case is described in Section 4.5 of <xref target="RFC7376" />.  While it is possible for a TURN server to use the same authentication credentials across many domains, a more likely (and more manageable) scenario is to have separate credentials for each domain, and hence a different realm for each domain.  With the TURN server configured with a mapping between a domain (conveyed in the Origin) and the realm string (to be used in the authentication challenge), a single TURN URI could be used across all domains, and the resulting JavaScript code would be portable.
</t>
<t>
Note that the origin information is most useful as a hint in initial STUN and TURN requests as received by a server.  However, origin information still has value throughout the session even after authentication for logging and other purposes.</t>
<t>
The following sections of this document define the STUN ORIGIN attribute and define its usage.
</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

<section title="STUN ORIGIN attribute">
<t>
This specification defines how to apply the web origin concept and syntax of <xref target="RFC6454" /> to the STUN protocol. 
</t>
<t>
This specification defines a new Attribute to the STUN protocol <xref target="RFC5389" />.  The attribute is called ORIGIN and uses the syntax defined in Section 15 of  <xref target="RFC5389" />.  The number used for this in the type field is 0x802F, chosen in the comprehension optional range.  The value of ORIGIN is a variable-length value.  It MUST contain a UTF-8 <xref target="RFC3629" /> encoded sequence of characters.  Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes.  The size of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation.  HTTP origins are less than 267 characters (the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number).   
</t>
<t>
For a web browser (HTTP User Agent), the contents of the ORIGIN attribute is the unicode-serialization of an origin defined in Section 6.1 of <xref target="RFC6454" />.  The origin value included is the same as the Origin header field for an HTTP request generated from the web page that is creating the Peer Connection.  It does not include any string terminating (\x00) character in the serialization.
</t>
<t>
For a SIP User Agent <xref target="RFC3261" /> using STUN and TURN, the ORIGIN attribute is set to be the URI of the registrar server used by the User Agent (i.e. the Request-URI of a REGISTER method).  This is the full Request-URI component of the SIP ABNF defined in <xref target="RFC3261" />.  For example, a SIP user "sip:bob@biloxi.example.com" might register with the Request-URI of "sip:registrar.biloxi.example.com".
</t>
<t>
   For an XMPP client <xref target="RFC6120" /> using STUN and TURN, the ORIGIN
   attribute is an XMPP URI <xref target="RFC5122" /> representing the full domainpart
   of the client's Jabber ID (JID) as defined in the ABNF of <xref target="RFC6122" />; for example, if the
   client's JID is "juliet@im.example.com/balcony" then the ORIGIN
   attribute would be "xmpp:im.example.com".
</t>
<t>
Other contexts can define a usage of the ORIGIN attribute to use an appropriate URI or URL. 
</t>
<t>
If an ORIGIN attribute is not present in a request, it is up to the server how to handle the request.  For example, it could assume a default Origin.
</t>
<section title="STUN Usage">
<t>
For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client MUST include the ORIGIN attribute when the origin is a web origin. For other origins, such as SIP or XMPP, the STUN client SHOULD include the ORIGIN attribute.  </t>
<t><list>
<t>
Note that for privacy reasons, an empty ORIGIN attribute can be sent, as described in the Security Considerations.
</t>
</list>
</t>
<t>
A STUN server can derive additional information for logging and analytics about the request through the ORIGIN attribute, such as the source of the request.  For example, an enterprise STUN server might only reply to STUN binding requests from certain domains.    
</t>
</section>
<section title="TURN Usage">
<t>
When the origin is a web origin, TURN <xref target="RFC5766" /> Allocate requests MUST include the ORIGIN attribute.  For all other TURN requests, including the Send method, the use of the ORIGIN attribute is NOT RECOMMENDED.  For other origins, such as SIP or XMPP, TURN Allocate requests SHOULD include the ORIGIN attribute.  A TURN server can use the ORIGIN attribute to determine which REALM to include in the authentication challenge.  A TURN server can also use the ORIGIN attribute after authentication to provide appropriate service.  
</t>
</section>
<section title="NAT Behavior Discovery Usage">
<t>
For the NAT Behavior Discovery Usage in <xref target="RFC5780" />, the rules for STUN usage apply.
</t>
</section>
<section title="ICE Usage">
<t>
ICE <xref target="RFC5245" /> connectivity checks MUST NOT include the ORIGIN attribute.  Including the ORIGIN attribute leaks information about the site used by one peer to the other peer in the session.  
</t>
</section>
<section title="Media Keep-Alive Usage">
<t>
For media keep-alive STUN requests described in Section 20 of <xref target="RFC5245" />, the rules for ICE usage apply.
</t>
</section>
<section title="SIP Keep-Alive Usage">
<t>
For SIP keep-alive STUN requests described in <xref target="RFC5626" />, the use of the ORIGIN attribute is NOT RECOMMENDED.  No valid use cases for the ORIGIN attribute have been identified to date, and as a result the ORIGIN attribute will be ignored.
</t>
</section>

<section title="Multiple Origins">
<t>
Multiple Origins for HTTP Requests are described in Section 7.2 of <xref target="RFC6454" />.  Multiple origins can occur when the same resource is fetched by multiple origins at the same time (e.g. multiple tabs, windows, frames, etc.).  In the context of WebRTC, it doesn't make sense for a STUN binding or TURN allocation to be shared across origins (e.g. Peer Connections).  Based on their definitions, multiple SIP and XMPP origins also do not apply here.  Therefore, if a STUN request contains multiple origins, the first origin MUST be used and the remaining origins ignored.
</t>
</section>
</section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This specification, if approved, adds a new value to the IANA "STUN Attributes Registry" created by <xref target="RFC5389" />.  The ORIGIN attribute value is 0x802F. </t>

    </section>

<section anchor="Security" title="Security Considerations">
<t>
The security considerations of <xref target="RFC6454" /> apply to this extension.  Servers using the information present in the STUN ORIGIN attribute need to realize that this attribute could be set arbitrarily by a non-browser client or modified by an intermediary.  The method proposed in this document is not meant to replace existing STUN authentication mechanisms but to provide additional information to the server for logging and analytics and how to handle the request after authentication.  
</t><t>
Just as browsers do not allow a web application to set the HTTP Origin header field via JavaScript, web browsers (HTTP User Agents) MUST NOT allow a web application to set the STUN ORIGIN attribute through JavaScript.
</t><t>
While the STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request, MESSAGE-INTEGRITY is not present in the initial STUN message sent. As a result, an ORIGIN attribute could be modified or removed from a STUN request without the server knowing. DTLS or TLS transport SHOULD be used when integrity protection for the ORIGIN attribute is important. 
</t><t>
The STUN ORIGIN attribute has privacy implications.   As a result, TLS or DTLS transport SHOULD be used.  If STUN requests containing the origin attribute are not encrypted with TLS or DTLS, an on-path attacker could determine this information by inspecting STUN messages between the STUN client and STUN server.  This information is often available in other messages sent by the browser, such as DNS or HTTP requests.  However, in cases where secure HTTP is used, including the ORIGIN attribute over an unencrypted transport could leak this information.  In cases where privacy is paramount, but TLS or DTLS transport is not available, the ORIGIN attribute MAY be sent with an empty (null) origin value.  It is up to the server what to do when receiving such an empty origin.  The server could fail the request, or the server could assume an origin and attempt to process the request.
</t>
<t>
The STUN ORIGIN attribute also has privacy implications in that the origin information is shared with a STUN or TURN server which otherwise might not know this information.  This information could be used to track usage of real-time communication services.  A STUN or TURN server will always know the public IP address of each user, but the ORIGIN attribute provides more information about which service or provider is being used.  The particular STUN and TURN servers used are usually selected by the real-time communications service provider (i.e. the web provider for WebRTC or the SIP or XMPP service provider).  In addition, they are usually also run by the same provider, or by a trusted partner, especially for TURN.  However, a service or provider using an untrusted third party STUN or TURN server needs to recognize that the operator of the third party STUN or TURN server will learn the identity of the service or provider through this extension.    In cases where the STUN or TURN client does not wish to share origin information with the server for privacy reasons, the ORIGIN attribute MAY be sent with an empty (null) origin value.  It is up to the server what to do when receiving such an empty origin.  The server could fail the request, or the server could assume an origin and attempt to process the request.
</t>
</section>

<section title="Implementation Status">
<t>
Note to RFC Editor: Please remove this entire section prior to publication, including the reference to RFC 6982.
</t>
<t>
This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of
      this Internet-Draft, and is based on a proposal described in <xref target="RFC6982" />.  The description of implementations in this section is
      intended to assist the IETF in its decision processes in
      progressing drafts to RFCs.  Please note that the listing of any
      individual implementation here does not imply endorsement by the
      IETF.  Furthermore, no effort has been spent to verify the
      information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a
      catalog of available implementations or their features.  Readers
      are advised to note that other implementations may exist.
</t>
<t>
      According to <xref target="RFC6982" />, "this will allow reviewers and working
      groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented
      protocols more mature.  It is up to the individual working groups
      to use this information as they see fit".
</t>
<t>


Two proof-of-concept implementations have been created in support of this proposed standard.  One provides a WebRTC enabled browser that includes the appropriate STUN ORIGIN Attribute with the Origin insight known to the browser in STUN/TURN messages sent to servers.  The other provides an example of a multiple realms capable TURN server that takes advantage of Origin insight provided in the STUN ORIGIN Attribute.
</t>
<t>
A Chrome browser implementation has been created by Graham Yoakum and Ryan Yoakum (Skobalt LLC) and is freely licensed under the standard terms of the open source Chromium and WebRTC projects.  This proof-of-concept version of the Google Chrome browser (nicknamed 'Chromeo') sends Origin insight in STUN and TURN messages using the proposed new STUN ORIGIN attribute with a value of 0x802F (as initially proposed, however that value is easily changed in a single line of code).  'Chromeo' includes a Chrome flag to enable and disable this unique feature (and is by default disabled to prevent any non-intentional use of this feature until the standard is finalized).  This implementation is based on is draft-johnston-tram-stun-origin-02.
 </t>
<t>
Coordinated changes to both the WebRTC and Chromium open source projects have been formally submitted for consideration.  The two submitted change lists together implement the complete browser proof-of-concept.  'Chromeo' has been built for Linux and STUN protocol behavior has been verified using WireShark traces illustrating that proper STUN Origin attributes are being included in STUN/TURN messages sent by the browser to servers (screen captures of STUN messages illustrating the Origin attribute and content are available).
 </t>
<t>
The WebRTC and Chromium open source projects can be found at: http://www.webrtc.org/ and http://www.chromium.org/
</t><t> 
Google can choose to accept or modify the changes proposed for Chrome and other browser vendors can access and take advantage of the publicly available WebRTC and Chromium open source submissions as desired.  Hopefully this will enable browsers to quickly implement STUN Origin enhancements.
 </t>
<t>
A multiple realms capable advanced open source Origin enabled TURN server (named 'Coturn') has been created by Oleg Moskalenko and is freely licensed under the New BSD license.  This reference implementation and proof-of-concept provides a clone (a spin-off) of the rfc5766-turn-server project adding Origin-based multiple realms support.
 </t>
<t>
'Coturn' is backward-compatible with rfc5766-turn-server project but the code is more complex and it uses a different (also more complex) database structure.  It is the intent to add all IETF TRAM TURN server related capabilities to this project as they mature.  'Coturn' is publicly available and can be found at: https://code.google.com/p/coturn/
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to John Selbie, Tirumaleswar Reddy, Simon Perreault, Marc Petit-Huguenin, Andy Hutton, and Oleg Moskalenko for their feedback and reviews.  Special thanks to Graham Yoakum and Ryan Yoakum of Skobalt LLC and Oleg Moskalenko of rfc5766-turn-server project for contributing open source proof-of-concept implementations for a Chrome web browser and a multiple realms capable TURN server, quickly demonstrating feasibility.
</t>
</section>



  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"?>

     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml"?>            
      
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"?>  
      
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml"?> 
            
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5122.xml"?>
                  
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6122.xml"?> 
                  
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7350.xml"?> 
                
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml"?>
               
    </references>
    
        <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      
            <?rfc include="reference.I-D.ietf-rtcweb-overview.xml"?>

      <reference anchor='WebRTC-API'
           target='http://www.w3.org/TR/2013/WD-webrtc-20130910/'>
  <front>
    <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
    <author fullname='Adam Bergkvist' surname='Bergkvist' initials='A. '/>
    <author fullname='Daniel C. Burnett' surname='Burnett' initials='D. '/>
    <author fullname='Cullen Jennings' surname='Jennings' initials='C. '/>
    <author fullname='Anant Narayanan' surname='Narayanan' initials='A. '/>
    <date year="2013" />
  </front>
  <seriesInfo name='W3C Working Draft' value='http://www.w3.org/TR/webrtc/'/>
</reference>
      
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7376.xml"?> 
      
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5780.xml"?>

     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml"?>            

      </references>

   </back>
</rfc>