1;4 7661054
`
`ilditumiatruituitiminitnitinuommminnninnimmummutu ituunuutmuuuntimothil Ontontaligail
`
`
`
`glift&BNECIAVELOWIIHESEIBRIECSENX* MUIR gintill%
`
`UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and Trademark Office
`
`June 06, 2018
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`RECORDS OF THIS OFFICE OF THE FILE WRAPPER AND CONTENTS
`OF:
`
`APPLICATION NUMBER: 13/079,767
`FILING DATE: April 04, 2011
`PATENT NUMBER: 8,018,877
`ISSUE DATE: September 13, 2011
`
`By Authority of the
`Under Secretary of Commerce for Intellectual Property
`and Director of the United States Patent and Trademark Office
`
`P. R. GRANT
`Certifying Officer
`
`Apple Inc.
`Ex. 1003 - Page 1
`
`

`

`PTO/SB/08a (07-09)
`Doc code: IDS
`Approved for use through 07/31/2012. OMB 0651-0031
`Doc description: Information Disclosure Statement (IDS) Filed
`U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it contains a valid OMB control number.
`
`INFORMATION DISCLOSURE
`STATEMENT BY APPLICANT
`( Not for submission under 37 CFR 1.99)
`
`Application Number
`
`Filing Date
`
`First Named Inventor Daniel J. Lin
`
`Art Unit
`
`Examiner Name
`
`Attorney Docket Number
`
`LIN/0002.C4
`
`U.S.PATENTS
`
`Examiner
`Initial*
`
`Cite
`No
`
`Patent Number
`
`Kind
`Code1
`
`Issue Date
`
`Name of Patentee or Applicant
`
`
`of cited Document
`
`Pages,Columns,Lines where
`Relevant Passages or Relevant
`Figures Appear
`
`1
`
`If you wish to add additional U.S. Patent citation information please click the Add button.
`
`U.S.PATENT APPLICATION PUBLICATIONS
`
`Examiner
`Initial*
`
`Cite
`No
`
`Publication Number
`
`Kind
`Codel
`
`Publication
`Date
`
`Name of Patentee or Applicant
`
`
`of cited Document
`
`Pages,Columns,Lines where
`Relevant Passages or Relevant
`Figures Appear
`
`1
`
`If you wish to add additional U.S. Published Application citation information please click the Add button.
`
`FOREIGN PATENT DOCUMENTS
`
`Examiner
`Examiner
`Initial*
`
`Cite
`No
`
`Foreign Document
`Number3
`
`Country
`Code2 i
`
`Kind
`Code4
`
`Publication
`Date
`
`of Patentee or
`Applicant of cited
`Document
`
`Pages,Columns,Lines
`where Relevant
`Passages or Relevant
`
`Figures Appear
`
`T5
`
`1
`
`q
`
`If you wish to add additional Foreign Patent Document citation information please click the Add button
`NON-PATENT LITERATURE DOCUMENTS
`
`Examiner
`Initials*
`
`Cite
`No
`
`Include name of the author (in CAPITAL LETTERS), title of the article (when appropriate), title of the item
`(book, magazine, journal, serial, symposium, catalog, etc), date, pages(s), volume-issue number(s),
`publisher, city and/or country where published.
`
`T5
`
`EFS Web 2.1.16
`
`Apple Inc.
`Ex. 1003 - Page 2
`
`

`

`INFORMATION DISCLOSURE
`STATEMENT BY APPLICANT
`( Not for submission under 37 CFR 1.99)
`
`Application Number
`
`Filing Date
`
`First Named Inventor Daniel J. Lin
`
`Art Unit
`
`Examiner Name
`
`Attorney Docket Number
`
`LIN/0002.C4
`
`1
`
`J. ROSENBERG, et al., Traversal Using Relay NAT (TURN) draft - rosenberg-midcom-turn-07, MIDCOM February 21,
`2005, pages 1-33
`
`If you wish to add additional non-patent literature document citation information please click the Add button
`EXAMINER SIGNATURE
`
`Examiner Signature
`
`Date Considered
`
`*EXAMINER: Initial if reference considered, whether or not citation is in conformance with MPEP 609. Draw line through a
`citation if not in conformance and not considered. Include copy of this form with next communication to applicant.
`
`Patent Documents at www.USPTO GOV or MPEP 901.04. 2 Enter office that issued the document, by the two-letter code (WIPO
`1 See Kind Codes of USPTO
`must precede the serial number of the patent document.
`patent documents, the indication of the year of the reign of the Emperor
`Standard ST.3). 3 For Japanese
`ST.16 if possible. 5 Applicant is to place a check mark here if
`appropriate symbols as indicated on the document under WIPO Standard
`4 Kind of document by the
`
`English language translation is attached.
`
`EFS Web 2.1.16
`
`Apple Inc.
`Ex. 1003 - Page 3
`
`

`

`INFORMATION DISCLOSURE
`STATEMENT BY APPLICANT
`( Not for submission under 37 CFR 1.99)
`
`Application Number
`
`Filing Date
`First Named Inventor Daniel J. Lin
`
`Art Unit
`
`Examiner Name
`
`Attorney Docket Number
`
`LIN/0002.C4
`
`CERTIFICATION STATEMENT
`
`Please see 37 CFR 1.97 and 1.98 to make the appropriate selection(s):
`
`That each item of information contained in the information disclosure statement was first cited in any communication
`q from a foreign patent office in a counterpart foreign application not more than three months prior to the filing of the
`information disclosure statement. See 37 CFR 1.97(e)(1).
`
`OR
`
`That no item of information contained in the information disclosure statement was cited in a communication from a
`foreign patent office in a counterpart foreign application, and, to the knowledge of the person signing the certification
`after making reasonable inquiry, no item of information contained in the information disclosure statement was known to
`q any individual designated in 37 CFR 1.56(c) more than three months prior to the filing of the information disclosure
`statement. See 37 CFR 1.97(e)(2).
`
`See attached certification statement.
`q Fee set forth in 37 CFR 1.17 (p) has been submitted herewith.
`q None
`
`>
`SIGNATURE
`A signature of the applicant or representative is required in accordance with CFR 1.33, 10.18. Please see CFR 1.4(d) for the
`form of the signature.
`
`Signature
`
`Name/Print
`
`441-1/1 W/ 02). /.&1-
`Frederick D. Kim
`
`Date (YYYY-MM-DD)
`
`2011-04-04
`
`Registration Number
`
`38513
`
`This collection of information is required by 37 CFR 1.97 and 1.98. The information is required to obtain or retain a benefit by the
`public which is to file (and by the USPTO to process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR
`1.14. This collection is estimated to take 1 hour to complete, including gathering, preparing and submitting the completed
`application form to the USPTO. Time will vary depending upon the individual case. Any comments on the amount of time you
`require to complete this form and/or suggestions for reducing this burden, should be sent to the Chief Information Officer, U.S.
`Patent and Trademark Office, U.S. Department of Commerce, P.O. Box 1450, Alexandria, VA 22313-1450. DO NOT SEND
`FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Commissioner for Patents, P.O. Box 1450, Alexandria,
`VA 22313-1450.
`
`EFS Web 2.1.16
`
`Apple Inc.
`Ex. 1003 - Page 4
`
`

`

`MIDCOM
`Internet-Draft
`Expires: August 22, 2005
`
`J. Rosenberg
`Cisco Systems
`R. Mahy
`Airspace
`C. Huitema
`Microsoft
`February 21, 2005
`
`Traversal Using Relay NAT (TURN)
`draft-rosenberg-midcom-turn-07
`
`Status of this Memo
`
`This document is an Internet-Draft and is subject to all provisions
`of section 3 of RFC 3667. By submitting this Internet-Draft, each
`author represents that any applicable patent or other IPR claims of
`which he or she is aware have been or will be disclosed, and any of
`which he or she become aware will be disclosed, in accordance with
`RFC 3668.
`
`Internet-Drafts are working documents of the Internet Engineering
`Task Force (IETF), its areas, and its working groups. Note that
`other groups may also distribute working documents as
`Internet-Drafts.
`
`Internet-Drafts are draft documents valid for a maximum of six months
`and may be updated, replaced, or obsoleted by other documents at any
`time. It is inappropriate to use Internet-Drafts as reference
`material or to cite them other than as "work in progress."
`
`The list of current Internet-Drafts can be accessed at
`http://www.ietf.org/ietf/1id-abstracts.txt.
`
`The list of Internet-Draft Shadow Directories can be accessed at
`http://www.ietf.org/shadow.html.
`
`This Internet-Draft will expire on August 22, 2005.
`
`Copyright Notice
`
`Copyright (C) The Internet Society (2005).
`
`Abstract
`
`Traversal Using Relay NAT (TURN) is a protocol that allows for an
`element behind a NAT or firewall to receive incoming data over TCP or
`UDP connections. It is most useful for elements behind symmetric
`NATs or firewalls that wish to be on the receiving end of a
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 1]
`
`Apple Inc.
`Ex. 1003 - Page 5
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`connection to a single peer TURN does not allow for users to run
`servers on well known ports if they are behind a nat; it supports the
`connection of a user behind a nat to only a single peer. In that
`regard, its role is to provide the same security functions provided
`by symmetric NATs and firewalls, but to "turn" them into
`port-restricted NATs.
`
`Table of Contents
`
`1. Introduction
`2. Terminology
`3. Definitions
`4. Applicability Statement
`5. Overview of Operation
`6. Message Overview
`7. Server Behavior
`7.1 Shared Secret Request
`7.2 Allocate Request
`7.2.1 Overview
`7.2.2 Initial Requests
`7.2.3 Subsequent Requests
`7.3 Send Request
`7.4
`Receiving Packets and Connections
`Lifetime Expiration
`7.5
`8. Client Behavior
`8.1 Discovery
`8.2 Obtaining a One Time Password
`8.3 Allocating a Binding
`8.4 Processing Allocate Responses
`8.5 Refreshing a Binding
`8.6 Sending Data
`8.7 Tearing Down a Binding
`8.8 Receiving and Sending Data
`9. Protocol Details
`9.1 Message Types
`9.2 Message Attributes
`9.2.1 LIFETIME
`9.2.2 ALTERNATE-SERVER
`9.2.3 MAGIC-COOKIE
`9.2.4 BANDWIDTH
`9.2.5 DESTINATION-ADDRESS
`9.2.6 SOURCE-ADDRESS
`9.2.7 DATA
`9.2.8 NONCE
`9.2.9 Response Codes
`10. Security Considerations
`11. IAB Considerations
`11.1 Problem Definition
`
` 4
` 4
` 4
` 5
` 5
` 7
` 7
` 8
` 10
` 10
` 10
` 13
` 14
` 15
` 17
` 17
` 17
` 18
` 19
` 20
` 21
` 21
` 22
` 22
` 23
` 23
` 23
` 23
` 24
` 24
` 24
` 24
` 24
` 25
` 25
` 25
` 25
` 27
` 27
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 2]
`
`Apple Inc.
`Ex. 1003 - Page 6
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`11.2 Exit Strategy
`11.3 Brittleness Introduced by TURN
`11.4 Requirements for a Long Term Solution
`11.5 Issues with Existing NAPT Boxes
`12. Examples
`13. References
`13.1 Normative References
`13.2 Informative References
`Authors' Addresses
`Intellectual Property and Copyright Statements
`
` 27
` 28
` 29
` 29
` 29
` 29
` 29
` 30
` 30
` 32
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 3]
`
`Apple Inc.
`Ex. 1003 - Page 7
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`1. Introduction
`
`Network Address Translators (NATs), while providing many benefits,
`also come with many drawbacks. The most troublesome of those
`drawbacks is the fact that they break many existing IP applications,
`and make it difficult to deploy new ones. Guidelines [9] have been
`developed that describe how to build "NAT friendly" protocols, but
`many protocols simply cannot be constructed according to those
`guidelines. Examples of such protocols include multimedia
`applications and file sharing.
`
`Simple Traversal of UDP Through NAT (STUN) [1] provides one means for
`an application to traverse a NAT. STUN allows a client to obtain a
`transport address (and IP address and port) which may be useful for
`receiving packets from a peer. However, addresses obtained by STUN
`may not be usable by all peers. Those addresses work depending on
`the topological conditions of the network. Therefore, STUN by itself
`cannot provide a complete solution for NAT traversal.
`
`A complete solution requires a means by which a client can obtain a
`transport address from which it can receive media from any peer which
`can send packets to the public Internet. This can only be
`accomplished by relaying data though a server that resides on the
`public Internet. This specification describes Traversal Using Relay
`NAT (TURN), a protocol that allows a client to obtain IP addresses
`and ports from such a relay.
`
`Although TURN will almost always provide connectivity to a client, it
`comes at high cost to the provider of the TURN server. It is
`therefore desirable to use TURN as a last resort only, preferring
`other mechanisms (such as STUN or direct connectivity) when possible.
`To accomplish that, the Interactive Connectivity Establishment (ICE)
`[13] methodology can be used to discover the optimal means of
`connectivity.
`
`2. Terminology
`
`In this document, the key words MUST, MUST NOT, REQUIRED, SHALL,
`SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to
`be interpreted as described in RFC 2119 [2] and indicate requirement
`levels for compliant TURN implementations.
`
`3. Definitions
`
`TURN Client: A TURN client (also just referred to as a client) is
`an entity that generates TURN requests. A TURN client can be an
`end system, such as a Session Initiation Protocol (SIP) [6] User
`Agent, or can be a network element, such as a Back-to-Back User
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 4]
`
`Apple Inc.
`Ex. 1003 - Page 8
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`Agent (B2BUA) SIP server. The TURN protocol will provide the TURN
`client with IP addresses that route to it from the public
`Internet.
`
`TURN Server: A TURN Server (also just referred to as a server) is
`an entity that receives TURN requests, and sends TURN responses.
`The server is capable of acting as a data relay, receiving data on
`the address it provides to clients, and forwarding them to the
`clients.
`
`Transport Address: An IP address and port.
`
`4 Applicability Statement
`
`TURN is useful for applications that require a client to place a
`transport address into a protocol message, with the expectation that
`the client will be able to receive packets from a single host that
`will send to this address. Examples of such protocols include SIP,
`which makes use of the Session Description Protocol (SDP) [7]. SDP
`carries and IP address on which the client will receive media packets
`from its peer. Another example of a protocol meeting this criteria
`is the Real Time Streaming Protocol (RTSP) [8].
`
`When a client is behind a NAT, transport addresses obtained from the
`local operating system will not be publically routable, and
`therefore, not useful in these protocols. TURN allows a client to
`obtain a transport address, from a server on the public Internet,
`which can be used in protocols meeting the above criteria. However,
`the transport addresses obtained from TURN servers are not generally
`useful for receiving data from anywhere. They are only useful for
`communicating with a single peer. This is accomplished by having the
`TURN server emulate the behavior of a port-restricted NAT. In
`particular, the TURN server will only relay packets from an external
`IP address and port towards the client if the client had previously
`sent a packet through the TURN server towards that IP address and
`port. As a result of this, when a TURN server is placed in front of
`a symmetric NAT, the resulting combined system has identical security
`properties to a system that just had a port-restricted NAT. Since
`clients behind such devices cannot run public servers, they cannot
`run them behind TURN servers either.
`
`5. Overview of Operation
`
`The typical TURN configuration is shown in Figure 1. A TURN client
`is connected to private network 1. This network connects to private
`network 2 through NAT 1. Private network 2 connects to the public
`Internet through NAT 2. On the public Internet is a TURN server.
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 5]
`
`Apple Inc.
`Ex. 1003 - Page 9
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`I
`
`\
`/
`// TURN \\
`Server 1
`//
`\\
`\
`/
`
`+
`
`+
`
`+
` I
`+
`
`NAT 2
`
`NAT 1
`
`+
`
`+
`
`+
`
`+
`
`I
`
`\
`/
`// TURN \\
`Client I
`//
`/
`
`\\
`\
`
`Figure 1
`
`Public Internet
`
`Private NET 2
`
`Private NET 1
`
`TURN is a simple client-server protocol. It is identical in syntax
`and general operation to STUN, in order to facilitate a joint
`implementation of both. TURN defines a request message, called
`Allocate, which asks for a public IP address and port. TURN can run
`over UDP and TCP, as it allows for a client to request address/port
`pairs for receiving both UDP and TCP.
`
`A TURN client first discovers the address of a TURN server. This can
`be preconfigured, or it can be discovered using SRV records [3] This
`will allow for different TURN servers for UDP and TCP. Once a TURN
`server is discovered, the client sends a TURN Allocate request to the
`TURN server. TURN provides a mechanism for mutual authentication and
`integrity checks for both requests and responses, based on a shared
`secret. Assuming the request is authenticated and has not been
`tampered with, the TURN server remembers the source transport address
`that the request came from (call this SA), and returns a public
`transport address, PA, in the TURN response. The TURN server is
`responsible for guaranteeing that packets sent to PA route to the
`TURN server. However, the TURN server will not relay any packets
`from PA to SA until the client sends a packet through the TURN server
`towards a correspondent. To do that, a client sends a TURN SEND
`command, which includes a data packet and a destination IP address
`and port. The TURN server, upon receipt of this command, will
`forward the packet to that IP address and port, add a "permission"
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 6]
`
`Apple Inc.
`Ex. 1003 - Page 10
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`for that IP address and port, so that inbound packets from that
`address and port are permitted, and set the default destination
`address to that address and port. From that point forward, non-TURN
`UDP packets sent from the client to the TURN server are relayed to
`this default IP address and port. Packets received from this IP
`address and port are relayed to the client. If a packet arrives from
`an IP address and port for which there is a permission, but which is
`not the current default destination IP address and port, the TURN
`server forwards this packet to the client wrapped in a DATA command,
`which informs the client of the source IP address and port.
`
`For TCP, the TURN server does not need to examine the data received;
`it merely forwards all data between the socket pairs it has
`associated together. In the case of UDP, the TURN server looks for a
`magic cookie in the first 128 bytes of each UDP packet. If present,
`it indicates that the packet is a TURN control packet, used for
`keepalives and teardown of the binding. In the case of TCP, if
`either side closes a connection, the TURN server closes the other
`connection. For both UDP and TCP, the TURN server can also time out
`a connection in the event data is not received after some configured
`time out period. This period is sent to the client in the TURN
`response to the Allocate request.
`
`6. Message Overview
`
`TURN messages are identical to STUN messages in their syntax. TURN
`defines several new messages - the Allocate Request, the Allocate
`Response, the Allocate Error Response, the Send Request, the Send
`Response, the Send Error Response and the Data Indication. TURN also
`uses the Shared Secret Request, Shared Secret Response, and Shared
`Secret Error Response defined by STUN. TURN makes use of some of the
`STUN attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY,
`ERROR-CODE, and UNKNOWN-ATTRIBUTES) and also defines several of its
`own. Specifically, TURN adds the LIFETIME attribute, which allows
`the TURN server to tell the client when the binding will be released.
`It defines the MAGIC-COOKIE attribute, which allows the TURN client
`to find TURN messages in a stream of UDP packets. It defines the
`BANDWIDTH attribute, which allows a client to inform the server of
`the expected bandwidth usage on the connection. Finally, it defines
`the ALTERNATE-SERVER attribute, which allows the server to redirect
`the TURN client to connect to an alternate server.
`
`7. Server Behavior
`
`The server behavior depends on whether the request is a Shared Secret
`Request or an Allocate Request.
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 7]
`
`Apple Inc.
`Ex. 1003 - Page 11
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`7.1 Shared Secret Request
`
`Unlike a STUN server, a TURN server provides resources to clients
`that connect to it. Therefore, only authorized clients can gain
`access to a TURN server. This requires that TURN requests be
`authenticated. TURN assumes the existence of a long-lived shared
`secret between the client and the TURN server in order to achieve
`this authentication. The client uses this long-lived shared secret
`to authenticate itself in a Shared Secret Request, sent over TLS.
`The Shared Secret Response provides the client with a one-time
`username and password. This one-time credential is then used by the
`server to authenticate an Allocate Request. The usage of a separate
`long lived and one-time credentials prevents dictionary attacks,
`whereby an observer of a message and its HMAC could guess the
`password by an offline dictionary search.
`
`When a TURN server receives a Shared Secret Request, it first
`executes the processing described in the first three paragraphs of
`Section 8.2 of STUN. This processing will ensure that the Shared
`Secret Request is received over TLS.
`
`Assuming it was, the server checks the Shared Secret Request for a
`MESSAGE-INTEGRITY attribute. If not present, the server generates a
`Shared Secret Error Response with an ERROR-CODE attribute with
`response code 401. That response MUST include a NONCE attribute,
`containing a nonce that the server wishes the client to reflect back
`in a subsequent Shared Secret Request (and therefore include the
`message integrity computation). The response MUST include a REALM
`attribute, containing a realm from which the username and password
`are scoped [4].
`
`If the MESSAGE-INTEGRITY attribute was present, the server checks for
`the existence of the REALM attribute. If the attribute is not
`present, the server MUST generate a Shared Secret Error Response.
`That response MUST include an ERROR-CODE attribute with response code
`434. That response MUST include a NONCE and a REALM attribute.
`
`If the REALM attribute was present, the server checks for the
`existence of the NONCE attribute. If the NONCE attribute is not
`present, the server MUST generate a Shared Secret Error Response.
`That response MUST include an ERROR-CODE attribute with response code
`435. That response MUST include a NONCE attribute and a REALM
`attribute.
`
`If the NONCE attribute was present, the server checks for the
`existence of the USERNAME attribute. If it was not present, the
`server MUST generate a Shared Secret Error Response. The Shared
`Secret Error Response MUST include an ERROR-CODE attribute with
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 8]
`
`Apple Inc.
`Ex. 1003 - Page 12
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`response code 432. It MUST include a NONCE attribute and a REALM
`attribute.
`
`If the USERNAME is present, the server computes the HMAC over the
`request as described in Section 11.2.8 of STUN. The key is computed
`as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where
`the password is the password associated with the username and realm
`provided in the request. If the server does not have a record for
`that username within that realm, the server generates a Shared Secret
`Error Response. That response MUST include an ERROR-CODE attribute
`with response code 436. That response MUST include a NONCE attribute
`and a REALM attribute.
`
`This format for the key was chosen so as to enable a common
`authentication database for SIP and for TURN, as it is expected
`that credentials are usually stored in their hashed forms.
`
`If the computed HMAC differs from the one from the MESSAGE-INTEGRITY
`attribute in the request, the server MUST generate a Shared Secret
`Error Response with an ERROR-CODE attribute with response code 431.
`This response MUST include a NONCE attribute and a REALM attribute.
`
`If the computed HMAC doesn't differ from the one in the request, but
`the nonce is stale, the server MUST generate a Shared Secret Error
`Response. That response MUST include an ERROR-CODE attribute with
`response code 430. That response MUST include a NONCE attribute and
`a REALM attribute.
`
`In all cases, the Shared Secret Error Response is sent over the TLS
`connection on which the Shared Secret Request was received.
`
`The server proceeds to authorize the client. The means for
`authorization are outside the scope of this specification. It is
`anticipated that TURN servers will be run by providers that also
`provide an application service, such as SIP or RTSP. In that case, a
`user would be authorized to use TURN if they are authorized to use
`the application service.
`
`The server then generates a Shared Secret Response as in Section 8.2
`of STUN. This response will contain a USERNAME and PASSWORD, which
`are used by the client as a short-term shared secret in subsequent
`Allocate requests. Note that STUN specifies that the server has to
`invalidate this username and password after 30 minutes. This is not
`the case in TURN. In TURN, the server MUST store the allocated
`username and password for a duration of at least 30 minutes Once an
`Allocate request has been authenticated using that username and
`password, if the result was an Allocate Error Response, the username
`and password are discarded. If the result was an Allocate Response,
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 9]
`
`Apple Inc.
`Ex. 1003 - Page 13
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`resulting in the creation of a new binding, the username and password
`become associated with that binding. They can only be used to
`authenticate Allocate requests sent from the same source transport
`address in order to refresh or de-allocate that binding. Once the
`binding is deleted, the username and password are discarded.
`
`This policy avoids replay attacks, whereby a recorded Allocate
`request is replayed in order to obtain a binding without proper
`authentication. It also ensures that existing bindings can be
`refreshed without needed to continuously obtain one-time passwords
`from the TURN server.
`
`7.2 Allocate Request
`
`7.2.1 Overview
`
`Allocate requests are used to obtain an IP address and port that the
`client can use to receive UDP and TCP packets from any host on the
`network, even when the client is behind a symmetric NAT. To do this,
`a TURN server allocates a local transport address, and passes it to
`the client in an Allocate Response. The server also maintains, for
`each local transport address, a list of permissions. These
`permissions are IP address and port combinations that the client has
`directed a request to, using the SEND primitive. The server
`maintains an IP address and port called the default destination.
`This is the default destination for non-TURN packets received from
`the client.
`
`The server maintains a set of bindings. These bindings are
`associations between the five-tuple of received Allocate requests
`(source IP address and port, destination IP address and port, and
`protocol), called the allocate five-tuple, and another five tuple,
`called the remote five-tuple.
`
`The behavior of the server when receiving an Allocate Request depends
`on whether the request is an initial one, or a subsequent one. An
`initial request is one received with a source transport address which
`is not associated with any existing bindings. A subsequent request
`is one received that is associated with an existing binding.
`
`7.2.2 Initial Requests
`
`A TURN server MUST be prepared to receive Binding Requests over TCP
`and UDP. The port on which to listen is based on the DNS SRV entries
`provided by the server. Typically, this will be XXXX, the default
`TURN port.
`
`The server MUST check the Allocate Request for a MESSAGE-INTEGRITY
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 10]
`
`Apple Inc.
`Ex. 1003 - Page 14
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`attribute. If not present, the server generates a Allocate Error
`Response with an ERROR-CODE attribute with response code 401.
`
`If the MESSAGE-INTEGRITY attribute was present, the server checks for
`the existence of the USERNAME attribute. If it was not present, the
`server MUST generate a Allocate Error Response. The Allocate Error
`Response MUST include an ERROR-CODE attribute with response code 432.
`
`If the USERNAME is present, the server computes the HMAC over the
`request as described in Section 11.2.8 of STUN. The key is equal to
`the password associated with the username in the request, where that
`username is a short term username allocated by the TURN server. The
`username MUST be one which has been allocated by the server in a
`Shared Secret Response, but has not yet been used to authenticate an
`Allocate request. If that username is not known by the server, or
`has already been used, the server generates an Allocate Error
`Response. That response MUST include an ERROR-CODE attribute with
`response code 430.
`
`If the computed HMAC differs from the one from the MESSAGE-INTEGRITY
`attribute in the request, the server MUST generate a Allocate Error
`Response with an ERROR-CODE attribute with response code 431.
`
`Assuming the message integrity check passed, processing continues.
`The server MUST check for any attributes in the request with values
`less than or equal to 0x7fff which it does not understand. If it
`encounters any, the server MUST generate an Allocate Error Response,
`and it MUST include an ERROR-CODE attribute with a 420 response code.
`
`That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing
`the attributes with values less than or equal to 0x7fff which were
`not understood.
`
`If the Allocate request arrived over TCP, the Allocate Error Response
`is sent on the connection from which the request arrived. If the
`Allocate request arrived over UDP, the Allocate Error Response is
`sent to the transport address from which the request was received
`(i.e., the source IP address and port), and sent from the transport
`address on which the request was received (i.e., the destination IP
`address and port).
`
`Assuming the Allocate request was authenticated and was well-formed,
`the server attempts to allocate transport addresses. It first looks
`for the BANDWIDTH attribute for the request. If present, the server
`determines whether or not it has sufficient capacity to handle a
`binding that will generate the requested bandwidth. If it does, the
`server attempts to allocate a port for the client. The server MUST
`NOT allocate ports from the well-known port range (0-1023) and MUST
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 11]
`
`Apple Inc.
`Ex. 1003 - Page 15
`
`

`

`Internet-Draft
`
`TURN
`
`February 2005
`
`NOT allocate ports from the user registered port range (1024 through
`49151).
`
`If a port meeting the bandwidth constraints cannot be allocated, the
`server MUST generate a Allocate Error Response that includes an
`ERROR-CODE attribute with a response code of 300. That response MAY
`include an ALTERNATE-SERVER attribute pointing to an alternate server
`which can be used by the client.
`
`Once the port is allocated, the server creates a binding for it.
`This binding is a mapping between two five-tuples - the allocate
`five-tuple and the remote five-tuple. The allocate five-tuple is set
`to the five-tuple of the Allocate Request (that is, the protocol of
`the allocate five-tuple is set to the protocol of the Allocate
`Request (TCP or UDP), the source IP address and port of the allocate
`five-tuple are set to the source IP address and port in the Allocate
`Request, and the destination IP address and port of the allocate
`five-tuple are set to the destination IP address and port in the
`Allocate Request). The protocol in the remote five-tuple is set to
`the protocol from the Allocate Request. The source IP address of the
`remote five-tuple is set to the interface from which the port was
`allocated. The source port of the remote five-tuple is set to the
`allocated port. If the binding was allocated for TCP, the connection
`on which the Allocate request was received is associated with the
`allocate five-tuple in the binding.
`
`The server MUST remember the one-time username and password used to
`obtain the binding.
`
`If the LIFETIME attribute was present in the request, and the value
`is larger than the maximum duration the server is willing to use for
`the lifetime of the binding, the server MAY lower it to that maximum.
`However, the server MUST NOT increase the duration requested in the
`LIFETIME attribute. If there was no LIFETIME attribute, the server
`may choose a default duration at its discretion. In either cae, the
`resulting duration is added to the current time, and a timer is