idnits 2.17.1 draft-zeilenga-xmpp-multi-passwd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 March 2009) is 5505 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-saintandre-rfc3920bis-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental Isode Limited 4 Expires in six months 2 March 2009 6 Multiple Passwords per User in XMPP 7 9 Status of this Memo 11 This document is submitted primarily for discussion purposes. It not 12 necessarily expected to be published as an RFC. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF XMPP mailing list 16 . Please send editorial comments directly to the 17 author . 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright (c) 20008 IETF Trust and the persons identified as the 38 document authors. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document discusses use of multiple passwords (per user) in XMPP. 47 1. Multiple Passwords in XMPP 49 This paper was written as an alternative solution to a problem in XMPP 50 [XMPP] discussed in "Management and Use of Client Certificates for the 51 Extensible Messaging and Presence Protocol (XMPP)" [XMPP-SASL-CERT]: 53 An XMPP client typically needs a user name and a password to log 54 in to an XMPP server. Many clients provide a mechanism to store 55 these credentials so that a human user can automatically log in 56 without being prompted for the password. While this practice is 57 very user friendly, it can be a security risk, especially for 58 some devices. Mobile devices like a mobile phone or a laptop 59 might get stolen, providing the thief with the required 60 password. Mobile phones are particularly insecure: providing 61 the password on the keypad for each login is too complicated and 62 the risk of losing the phone is high. 64 This paper discusses an alternative solution to this problem. 66 This alternative solution is use multiple passwords per user. This 67 feature arguely already exists (as password mechanisms such as PLAIN 68 [RFC4616] do not restrict users to single passwords). Regardless, 69 This solution requires no change to the XMPP protocol, nor any change 70 to any existing authentication mechanism. 72 The server would provide mechanisms, likely via XMPP Ad-Hoc Commands 73 [XEP50], to establish, enable/disable, and other manage secondary 74 passwords for a user name. This may include placing restrictions upon 75 what a user authenticating with a secondary password (or a particular 76 secondary password) may do. For instance, the user might desire 77 restrict the resource binding based upon which password was used to 78 authenticate. 80 2. Security Considerations 82 There are some general security considerations of allowing multiple 83 passwords, or multiple credentials, per user, none of which are 84 terribly specific to this solution. [[Insert pointer to a general 85 discussion here]]. 87 This paper suggests distinguishing between a single primary password 88 and zero or more secondary passwords. This would allow, for instance, 89 restriction of new password creation/modification to a single 90 password, in hopes the user would tightly control use of this 91 password, while using secondary passwords with devices he likely to 92 lose (e.g., his phone). 94 This paper further suggests servers provide mechanisms for restricting 95 which resources a particular password can be used to bind to. This 96 is suggested as server implementors are likely to employ 97 Identity-based access controls, and Jabber Id's do contain a resource 98 component. 100 3. IANA Considerations 102 None. 104 4. Author's Address 106 Kurt D. Zeilenga 107 Isode Limited 109 Email: Kurt.Zeilenga@Isode.COM 111 5. References 113 [[Note to the RFC Editor: please replace the citation tags used in 114 referencing Internet-Drafts with tags of the form RFCnnnn where 115 possible.]] 117 5.1. Normative References 119 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 120 Protocol (XMPP): Core", draft-saintandre-rfc3920bis-08, 121 a work in progress). 123 5.2. Informational References 125 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 126 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 128 [XMPP-SASL-CERT] Meyer, Dirk and Peter Saint-Andre, "Management and 129 Use of Client Certificates for the Extensible Messaging 130 and Presence Protocol (XMPP)", draft-meyer-xmpp-sasl- 131 cert-management, a work in progress. 133 [XEP50] Miller, Matthew, "Ad-Hoc Commands", XMPP Standards 134 Foundation XEP 50, 135 , June 2005. 137 Full Copyright 139 Copyright (c) 2009 IETF Trust and the persons identified as the 140 document authors. All rights reserved. 142 This document is subject to BCP 78 and the IETF Trust's Legal 143 Provisions Relating to IETF Documents 144 (http://trustee.ietf.org/license-info) in effect on the date of 145 publication of this document. Please review these documents 146 carefully, as they describe your rights and restrictions with respect 147 to this document.