Network Working Group W. Wolfgang Internet-Draft Deutsche Telekom AG Intended status: Standards Track October 19, 2009 Expires: April 22, 2010 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. Wolfgang Expires April 22, 2010 [Page 1] Internet-Draft OAUTH suitability for SIP authentication October 2009 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 . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Architectural Overview . . . . . . . . . . . . . . . . . . 5 2.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Establishment of an MSRP session . . . . . . . . . . . 5 2.2.2. Gateway for browser-based VoIP applets . . . . . . . . 6 3. Resource Access Policies . . . . . . . . . . . . . . . . . . . 7 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. SIP MESSAGE . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. MSRP Call . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Wolfgang Expires April 22, 2010 [Page 2] Internet-Draft OAUTH suitability for SIP authentication October 2009 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]. Wolfgang Expires April 22, 2010 [Page 3] Internet-Draft OAUTH suitability for SIP authentication October 2009 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 [RFC3261] offers some resources that could be accessed by OAUTH clients as well: o The resource owner's identity can be used to make calls, change presence states, or send messages from a web application. o 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. Wolfgang Expires April 22, 2010 [Page 4] Internet-Draft OAUTH suitability for SIP authentication October 2009 2.1. Architectural Overview _OAUTH_ / \ +---------+ +---------+ +------------+ | +--HTTP-->| | | |<-----HTTP----->| client | | | | resource | | +--SIP--->| server | | owner | +---------+ | | | |<-----HTTP------------------------->| | +------------+ +----+----+ | | SIP | v other SIP systems SIP and OAUTH Figure 1 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]) 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. Wolfgang Expires April 22, 2010 [Page 5] Internet-Draft OAUTH suitability for SIP authentication October 2009 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. Wolfgang Expires April 22, 2010 [Page 6] Internet-Draft OAUTH suitability for SIP authentication October 2009 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 Wolfgang Expires April 22, 2010 [Page 7] Internet-Draft OAUTH suitability for SIP authentication October 2009 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. o OAUTH needs to define how to use SIP URIs in OAUTH signatures o 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. Wolfgang Expires April 22, 2010 [Page 8] Internet-Draft OAUTH suitability for SIP authentication October 2009 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 [I-D.hammer-oauth]. Wolfgang Expires April 22, 2010 [Page 9] Internet-Draft OAUTH suitability for SIP authentication October 2009 5. IANA Considerations None. Wolfgang Expires April 22, 2010 [Page 10] Internet-Draft OAUTH suitability for SIP authentication October 2009 6. Informative References [I-D.hammer-oauth] Hammer-Lahav, E. and B. Cook, "The OAuth Core 1.0 Protocol", draft-hammer-oauth-03 (work in progress), September 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. Wolfgang Expires April 22, 2010 [Page 11] Internet-Draft OAUTH suitability for SIP authentication October 2009 Author's Address Wolfgang Beck Deutsche Telekom AG Heinrich-Hertz Str 4-7 Darmstadt 64295 Germany Phone: +49 6151 628 0 Email: beckw@telekom.de Wolfgang Expires April 22, 2010 [Page 12]