One document matched: draft-ivov-sipxmpp-auth-00.txt

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]