idnits 2.17.1 draft-ivov-sipxmpp-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 193, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft SIP Communicator 4 Intended status: Informational E. Marocco 5 Expires: September 3, 2010 Telecom Italia 6 March 2, 2010 8 Problem Statement and Possible Best Practices for Authentication of SIP+ 9 XMPP Clients 10 draft-ivov-sipxmpp-auth-01 12 Abstract 14 This document discusses several mechanisms for simplifying 15 authentication of dual-stack SIP+XMPP clients against the 16 corresponding SIP and XMPP services. The text is not attempt to 17 define a complex credential sharing protocol but rather to determine 18 and eventually encourage use of a simple mechanism that would allow 19 service providers to host a SIP+XMPP solution appearing as a single 20 service to their users. In other words, the goal here is to agree on 21 a set of recommendations that would encourage client developers to 22 implement simple UIs that would only require users to provide an ID 23 and a password when configuring their SIP+XMPP account for the first 24 time (as opposed to having to do so separately for SIP and XMPP). 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 3, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Why it is important to have a common authentication 68 mechanism. . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Simply stating it ... . . . . . . . . . . . . . . . . . . . . . 4 70 3. Using the domain in the auth header in SIP or XMPP . . . . . . 4 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 74 7. Informative References . . . . . . . . . . . . . . . . . . . . 5 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 [TODO:ref-to-charter] and [TODO:ref-to-draft] define the requirements 80 and the semantics for combined use of SIP and XMPP servers. Among 81 other things, the combination allows providers to easily use SIP 82 server products with audio/video capabilities together with IM/ 83 presence XMPP ones when building platforms that provide all these 84 features in a single service. Both, the proposed charter, and the 85 draft solution make it clear that server side components should be 86 barely if at all modified and that the effort of making both 87 protocols function as one should be delegated to client-side 88 applications 90 The issue discussed in this problem statement is related to how such 91 client-side applications would be able to determine that a SIP and an 92 XMPP server operate together and that (or if) it would be able to 93 reuse the same set of user credentials (e.g. a user ID and a 94 password) when connecting to both of them. The purpose of this 95 document is to enumerate a ways that would allow this and discuss 96 their various pros and cons. 98 The document does not attempt to open the way for new protocol 99 extensions. The ideal result of this work would be a section in a 100 related specification, that defines a set of assumptions, which 101 clients would be able to make when discovering and connecting to SIP+ 102 XMPP networks, or a separate Best Practices document. 104 1.1. Why it is important to have a common authentication mechanism. 106 During a previous discussion which took place on the DISPATCH mailing 107 list, various individuals expressed the opinion that the issue at 108 hand need not be explicitly stated in an IETF document. 110 The Internet has already seen an example of a similar situation that 111 was left without a solution. The SMTP [TODO:reference] protocol is 112 often used in conjunction with either POP3 [TODO:reference] or IMAP 113 [TODO:reference] without any explicitly defined relation. As a 114 result, most e-mail clients require users to configure separately 115 their inbound and outbound mail accounts. The concept is often quite 116 confusing to inexperienced users. Some clients have therefore 117 started proposing per-provider account creation wizards which only 118 require users to fill in a user name and a password and then "fill 119 in" the rest according to the setup of the specific provider. 121 The above workaround is of course non-existent for average and small 122 size providers, and it requires an extra effort from application 123 developers that is clearly avoidable. 125 The following sections of this document briefly discuss simple ways 126 of addressing the issue. 128 2. Simply stating it ... 130 One relatively simple way of making sure that a URI and a password 131 would be enough to connect to a SIP+XMPP service would consist in 132 allowing clients to make the following assumptions: 133 o after applying the standard XMPP and SIP discovery mechanisms 134 using the supplied URI (i.e. looking up the corresponding SRV DNS 135 records), the client would discover the XMPP and SIP servers that 136 should be used for the newly configured XMPP+SIP account. 137 o The supplied URI and password could be used as authentication 138 credentials for both the XMPP and the SIP service. 139 Needless to say, clients may provide mechanisms (e.g. an "Advanced 140 Configuration" form) that allow users to override the above 141 assumptions and explicitly specify different connection points with 142 different sets of credentials. 144 The mechanism has the advantage of being relatively simple and 145 require no other modifications to server side products other than 146 making sure that user credentials would be valid for both the SIP and 147 XMPP deployments. In many cases however, this would be resolvable 148 through database synchronization and scripting, and hence be 149 applicable to existing server-side implementations. 151 3. Using the domain in the auth header in SIP or XMPP 153 Participants in the related discussions on the DISPATCH mailing list 154 also suggested using the "domain" parameter of the 'WWW-Authenticate' 155 headers used in SIP authentication challenges. If present such a 156 "domain" parameter may be used as an indication that the target URI 157 would allow XMPP connections with the same credentials. 159 The main advantage of this mechanism is the fact that it allows for a 160 discovery phase that is completely decoupled from the one used by 161 regular SIP and XMPP. This means that service providers could use 162 one set of servers to handle standard SIP and XMPP and then direct 163 users to different addresses for their SIP+XMPP services. 165 Contrary to the DNS-based mechanism however, relying on domain 166 parameters is more likely to require implementation changes since it 167 relies on the parameter being configurable. It hence represents more 168 of a contradiction with the requirements that XMPP+SIP work was 169 chartered with. 171 Other issues worth noting, are the reliance of this mechanism on 172 authentication methods that support the domain parameter, and the 173 fact that it adds a sequential dependency between the SIP and XMPP 174 authentication procedures. 176 4. Security Considerations 178 1. PENDING 180 5. IANA Considerations 182 None. 184 6. Acknowledgments 186 Simo Veikkolainen, Markus Isomaki, Peter St. Andre, Roni Even, Scott 187 Lawrence, Spencer Dawkins, and several others provided helpful 188 feedback in the related discussion that took place on the DISPATCH 189 mailing list. 191 7. Informative References 193 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 194 A., Peterson, J., Sparks, R., Handley, M., and E. 195 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 196 June 2002. 198 Authors' Addresses 200 Emil Ivov 201 SIP Communicator 202 Strasbourg 67000 203 France 205 Email: emcho@sip-communicator.org 206 Enrico Marocco 207 Telecom Italia 208 Via G. Reiss Romoli, 274 209 Turin 10148 210 Italy 212 Email: enrico.marocco@telecomitalia.it