Network Working Group E. Ivov
Internet-Draft SIP Communicator
Intended status: Informational E. Marocco
Expires: September 2, 2010 Telecom Italia
March 1, 2010
Problem Statement and Possible Best Practices for Authentication of SIP+
XMPP Clients
draft-ivov-sipxmpp-auth-00
Abstract
This document discusses several mechanisms for simplifying
authentication of dual-stack SIP+XMPP clients against the
corresponding SIP and XMPP services. The text is not attempt to
define a complex credential sharing protocol but rather to determine
and eventually encourage use of a simple mechanism that would allow
service providers to host a SIP+XMPP solution appearing as a single
service to their users. In other words, the goal here is to agree on
a set of recommendations that would encourage client developers to
implement simple UIs that would only require users to provide an ID
and a password when configuring their SIP+XMPP account for the first
time (as opposed to having to do so separately for SIP and XMPP).
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 September 2, 2010.
Ivov & Marocco Expires September 2, 2010 [Page 1]
Internet-Draft Discovery and Authenticationfor SIP+XMPP March 2010
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why it is important to have a common authentication
mechanism. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Simply stating it ... . . . . . . . . . . . . . . . . . . . . . 4
3. Using the domain in the auth header in SIP or XMPP . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Informative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Ivov & Marocco Expires September 2, 2010 [Page 2]
Internet-Draft Discovery and Authenticationfor SIP+XMPP March 2010
1. Introduction
[TODO:ref to charter] and [ref-to-draft] define the requirements and
the semantics for combined use of SIP and XMPP servers. Among other
things, the combination allows providers to easily use SIP server
products with audio/video capabilities together with IM/presence XMPP
ones when building platforms that provide all these features in a
single service. Both, the proposed charter, and the draft solution
make it clear that server side components should be barely if at all
modified and that the effort of making both protocols function as one
should be delegated to client-side applications
The issue discussed in this problem statement is related to how such
client-side applications would be able to determine that a SIP and an
XMPP server operate together and that (or if) it would be able to
reuse the same set of user credentials (e.g. a user ID and a
password) when connecting to both of them. The purpose of this
document is to enumerate a ways that would allow this and discuss
their various pros and cons.
The document does not attempt to open the way for new protocol
extensions. The ideal result of this work would be a section in a
related specification, that defines a set of assumptions, which
clients would be able to make when discovering and connecting to SIP+
XMPP networks, or a separate Best Practices document.
1.1. Why it is important to have a common authentication mechanism.
During a previous discussion which took place on the DISPATCH mailing
list, various individuals expressed the opinion that the issue at
hand need not be explicitly stated in an IETF document.
The Internet has already seen an example of a similar situation that
was left without a solution. The SMTP [TODO:reference] protocol is
often used in conjunction with either POP3 [TODO:reference] or IMAP
[TODO:reference] without any explicitly defined relation. As a
result, most e-mail clients require users to configure separately
their inbound and outbound mail accounts. The concept is often quite
confusing to inexperienced users. Some clients have therefore
started proposing per-provider account creation wizards which only
require users to fill in a user name and a password and then "fill
in" the rest according to the setup of the specific provider.
The above workaround is of course non-existent for average and small
size providers, and it requires an extra effort from application
developers that is clearly avoidable.
The following sections of this document briefly discuss simple ways
Ivov & Marocco Expires September 2, 2010 [Page 3]
Internet-Draft Discovery and Authenticationfor SIP+XMPP March 2010
of addressing the issue.
2. Simply stating it ...
One relatively simple way of making sure that a URI and a password
would be enough to connect to a SIP+XMPP service would consist in
allowing clients to make the following assumptions:
o after applying the standard XMPP and SIP discovery mechanisms
using the supplied URI (i.e. looking up the corresponding SRV DNS
records), the client would discover the XMPP and SIP servers that
should be used for the newly configured XMPP+SIP account.
o The supplied URI and password could be used as authentication
credentials for both the XMPP and the SIP service.
Needless to say, clients may provide mechanisms (e.g. an "Advanced
Configuration" form) that allow users to override the above
assumptions and explicitly specify different connection points with
different sets of credentials.
The mechanism has the advantage of being relatively simple and
require no other modifications to server side products other than
making sure that user credentials would be valid for both the SIP and
XMPP deployments. In many cases however, this would be resolvable
through database synchronization and scripting, and hence be
applicable to existing server-side implementations.
3. Using the domain in the auth header in SIP or XMPP
Participants in the related discussions on the DISPATCH mailing list
also suggested using the "domain" parameter of the 'WWW-Authenticate'
headers used in SIP authentication challenges. If present such a
"domain" parameter may be used as an indication that the target URI
would allow XMPP connections with the same credentials.
The main advantage of this mechanism is the fact that it allows for a
discovery phase that is completely decoupled from the one used by
regular SIP and XMPP. This means that service providers could use
one set of servers to handle standard SIP and XMPP and then direct
users to different addresses for their SIP+XMPP services.
Contrary to the DNS-based mechanism however, relying on domain
parameters is more likely to require implementation changes and hence
represents more of a contradiction with the requirements that XMPP+
SIP work was chartered with.
Ivov & Marocco Expires September 2, 2010 [Page 4]
Internet-Draft Discovery and Authenticationfor SIP+XMPP March 2010
4. Security Considerations
1. PENDING
5. IANA Considerations
None.
6. Acknowledgments
Peter St. Andre, Spencer Dawkins, Scott Lawrence and several others
provided helpful feedback in the related discussion that took place
on the DISPATCH mailing list.
7. Informative References
[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.
Authors' Addresses
Emil Ivov
SIP Communicator
Strasbourg 67000
France
Email: emcho@sip-communicator.org
Enrico Marocco
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
Email: enrico.marocco@telecomitalia.it
Ivov & Marocco Expires September 2, 2010 [Page 5]