INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Experimental Isode Limited Expires in six months 2 March 2009 Multiple Passwords per User in XMPP Status of this Memo This document is submitted primarily for discussion purposes. It not necessarily expected to be published as an RFC. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF XMPP mailing list . Please send editorial comments directly to the author . 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (c) 20008 IETF Trust and the persons identified as the document authors. Please see the Full Copyright section near the end of this document for more information. Zeilenga draft-zeilenga-xmpp-multi-passwds [Page 1] INTERNET-DRAFT XMPP Multiple Passwords 2 March 2009 Abstract This document discusses use of multiple passwords (per user) in XMPP. 1. Multiple Passwords in XMPP This paper was written as an alternative solution to a problem in XMPP [XMPP] discussed in "Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP)" [XMPP-SASL-CERT]: An XMPP client typically needs a user name and a password to log in to an XMPP server. Many clients provide a mechanism to store these credentials so that a human user can automatically log in without being prompted for the password. While this practice is very user friendly, it can be a security risk, especially for some devices. Mobile devices like a mobile phone or a laptop might get stolen, providing the thief with the required password. Mobile phones are particularly insecure: providing the password on the keypad for each login is too complicated and the risk of losing the phone is high. This paper discusses an alternative solution to this problem. This alternative solution is use multiple passwords per user. This feature arguely already exists (as password mechanisms such as PLAIN [RFC4616] do not restrict users to single passwords). Regardless, This solution requires no change to the XMPP protocol, nor any change to any existing authentication mechanism. The server would provide mechanisms, likely via XMPP Ad-Hoc Commands [XEP50], to establish, enable/disable, and other manage secondary passwords for a user name. This may include placing restrictions upon what a user authenticating with a secondary password (or a particular secondary password) may do. For instance, the user might desire restrict the resource binding based upon which password was used to authenticate. 2. Security Considerations There are some general security considerations of allowing multiple passwords, or multiple credentials, per user, none of which are terribly specific to this solution. [[Insert pointer to a general discussion here]]. This paper suggests distinguishing between a single primary password and zero or more secondary passwords. This would allow, for instance, Zeilenga draft-zeilenga-xmpp-multi-passwds [Page 2] INTERNET-DRAFT XMPP Multiple Passwords 2 March 2009 restriction of new password creation/modification to a single password, in hopes the user would tightly control use of this password, while using secondary passwords with devices he likely to lose (e.g., his phone). This paper further suggests servers provide mechanisms for restricting which resources a particular password can be used to bind to. This is suggested as server implementors are likely to employ Identity-based access controls, and Jabber Id's do contain a resource component. 3. IANA Considerations None. 4. Author's Address Kurt D. Zeilenga Isode Limited Email: Kurt.Zeilenga@Isode.COM 5. References [[Note to the RFC Editor: please replace the citation tags used in referencing Internet-Drafts with tags of the form RFCnnnn where possible.]] 5.1. Normative References [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", draft-saintandre-rfc3920bis-08, a work in progress). 5.2. Informational References [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006. [XMPP-SASL-CERT] Meyer, Dirk and Peter Saint-Andre, "Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP)", draft-meyer-xmpp-sasl- cert-management, a work in progress. Zeilenga draft-zeilenga-xmpp-multi-passwds [Page 3] INTERNET-DRAFT XMPP Multiple Passwords 2 March 2009 [XEP50] Miller, Matthew, "Ad-Hoc Commands", XMPP Standards Foundation XEP 50, , June 2005. Full Copyright 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 (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. Zeilenga draft-zeilenga-xmpp-multi-passwds [Page 4]