Evaluating OAUTH's suitability for SIP authentication
draft-beck-oauth-sip-eval-00.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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 April 22, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH's suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials.

Table of Contents

1.  Requirements notation
2.  Introduction
    2.1.  Architectural Overview
    2.2.  Use Cases
        2.2.1.  Establishment of an MSRP session
        2.2.2.  Gateway for browser-based VoIP applets
3.  Resource Access Policies
    3.1.  Use Cases
        3.1.1.  SIP MESSAGE
        3.1.2.  MSRP Call
    3.2.  Requirements
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
§  Author's Address

1.  Requirements notation

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] 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.

2.1.  Architectural Overview

       	       	       	       	       	       _OAUTH_
					      /       \

				   +---------+	       +---------+
     +------------+		   |         +--HTTP-->|         |
     |            |<-----HTTP----->| client  |	       |         |
     | resource   |		   |         +--SIP--->| server  |
     | owner      |		   +---------+	       |         |
     |            |<-----HTTP------------------------->|         |
     +------------+                      	       +----+----+
						       	    |
							    | SIP
							    |
							    v

						    other SIP systems

SIP and OAUTH

Figure 1 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.

2.2.  Use Cases

2.2.1.  Establishment of an MSRP session

Some web sites implement text chat using asynchronous HTTP requests (AJAX). To connect such web sites to SIP environments with SIP/MSRP (see [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.)) clients, a gateway can use OAUTH.

1. The user logs into a web site and the browser loads the embedded javascript code.
2. The web site's OAUTH client initiates an OAUTH exchange with the user's preferred SIP provider.
3. The web site redirects the user's browser to the authentication web page of the SIP provider's OAUTH server.
4. The user enters her credentials. The OAUTH server redirects her to the web site.
5. 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.

2.2.2.  Gateway for browser-based VoIP applets

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.

1. The user logs into a web site and the browser loads the embedded VoIP applet.
2. The web site's OAUTH client initiates an OAUTH exchange with the user's preferred SIP provider.
3. The web site redirects the user's browser to the authentication web page of the SIP provider's OAUTH server.
4. The user enters her credentials. The OAUTH server redirects her to the web site.
5. 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.

3.  Resource Access Policies

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.

3.1.  Use Cases

3.1.1.  SIP MESSAGE

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

3.1.2.  MSRP Call

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.

3.2.  Requirements

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.

4.  Security Considerations

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 (Hammer-Lahav, E. and B. Cook, “The OAuth Core 1.0 Protocol,” September 2009.) [I‑D.hammer‑oauth].

5.  IANA Considerations

None.

6. Informative References

Author's Address