Evaluating OAUTH's suitability for SIP authentication

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

OAUTH is an authentication delegation protocol, that allows a client to access resources on a server on behalf of a resource owner. An example would be a printing service -- OAUTH client -- that wants to access photos on a photo sharing site -- OAUTH server -- on behalf of a user -- OAUTH resource owner. The resource owner does not need to reveal her credentials to the OAUTH client. In a first phase, the client obtains token credentials from the server. Using these token credentials, the client can access resources on the server. Currently, this is only defined for HTTP requests. SIP offers some resources that could be accessed by OAUTH clients as well: The resource owner's identity can be used to make calls, change presence states, or send messages from a web application. The presence state of the resource owner's contacts can be retrieved, displayed, or used in a web application. The resource protected by OAUTH is the resource owner's SIP account and its associated data. While it would be possible to use SIP as a way to obtain temporary OAUTH credentials and to authenticate a resource owner, this document focuses on the access of SIP resources.

| | | |<-----HTTP----->| client | | | | resource | | +--SIP--->| server | | owner | +---------+ | | | |<-----HTTP------------------------->| | +------------+ +----+----+ | | SIP | v other SIP systems ]]> SIP and OAUTH shows the intended architecture. Triggered by the resource owner, the client acquires token credentials from the server. In the course of this, the server authenticates the resource owner and asks her for authorization of the client's request. Using the token credentials, the client then sends a SIP request to the server. The server checks the credentials and forwards the SIP request.

Some web sites implement text chat using asynchronous HTTP requests (AJAX). To connect such web sites to SIP environments with SIP/MSRP (see ) clients, a gateway can use OAUTH. The user logs into a web site and the browser loads the embedded javascript code. The web site's OAUTH client initiates an OAUTH exchange with the user's preferred SIP provider. The web site redirects the user's browser to the authentication web page of the SIP provider's OAUTH server. The user enters her credentials. The OAUTH server redirects her to the web site. The web site translates the text chat-related HTTP requests into SIP and MSRP. It adds OAUTH token credentials to the SIP requests it sends towards the user's preferred SIP provider. After this, the OAUTH server checks the token credentials for validity and checks if the SIP request complies to the policy the user has granted for this kind of transaction. If the SIP request passes all checks, the OAUTH server forwards it to the subsequent SIP nodes.

A number of technologies exist to implement VoIP clients as browser applets. To keep applet loading times low, vendors don't implement standard SIP, but use stripped-down variants or proprietary technology. The user logs into a web site and the browser loads the embedded VoIP applet. The web site's OAUTH client initiates an OAUTH exchange with the user's preferred SIP provider. The web site redirects the user's browser to the authentication web page of the SIP provider's OAUTH server. The user enters her credentials. The OAUTH server redirects her to the web site. The web site translates the web applets messages into SIP and RTP. It adds OAUTH token credentials to the SIP requests it sends towards the user's preferred SIP provider. After this, the OAUTH server checks the token credentials for validity and checks if the SIP request complies to the policy the user has granted for this kind of transaction. If the SIP request passes all checks, the OAUTH server forwards it to the subsequent SIP nodes.

In HTTP, the access to a resource is basically defined by the request method and the request URI. In SIP, the information that determines the action that needs to be policed is scattered all over the request. OAUTH -- like HTTP digest -- only signs the request method and request URI. Any OAUTH extension for SIP would have to define how to protect the relevant parts of a SIP request. The OAUTH server MUST be able to check if a request matches the resource owner's authorization.

In this use case, the resource owner wants to be sure that the OAUTH client is only able to send a SIP MESSAGE request, but not able to establish calls. The OAUTH client redirects the resource owner's browser to the OAUTH server's login page. After the resource owner successfully logged in, the OAUTH server asks: 'OAUTH client xy wants to send a SIP Instant Message Allow? Yes / No' The OAUTH client receives token credentials that are only valid for sending a SIP MESSAGE request The OAUTH server checks the SIP request and the token credentials it carries. If the request matches the policy associated with the token credential, it forwards the request

In this use case, the resource owner wants to be sure, that the OAUTH client will only be able to make an MSRP call When the OAUTH client redirects the resource owner's browser to the OAUTH server's login page, the OAUTH server checks her credentials and asks: 'OAUTH client xy wants to establish an MSRP session with sip:xy@example.com. Allow? Yes/No' The OAUTH client receives token credentials that are only valid for an MSRP call to sip:xy@example.com The OAUTH server checks the SIP request and the token credentials it carries. If the request matches the policy associated with the token credential, it forwards the request. If the OAUTH client tries to use the token credentials for a voice call, it rejects it.

It is desirable to keep SIP extensions as close as possible to the original specification. OAUTH needs to define how to use SIP URIs in OAUTH signatures The OAUTH server needs a signed piece of information in the SIP request that tells what policy the resource owner wants it to apply. For the use cases in this document, it is sufficient to have pre-defined policies between OAUTH client and OAUTH server. The policies can be part of the OAUTH server's API description. Dynamic negotiation of policies is not required.

With a SIP extension for OAUTH, the OAUTH server MUST be able to display to the resource owner what kind of SIP action the OAUTH client is intending to do. The OAUTH server MUST be able to check whether the SIP request matches the policy associated with the token credential it carries. For general security considerations of OAUTH, see the OAUTH base document.

None.