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]