idnits 2.17.1 draft-alkemade-xmpp-iq-validation-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 : ---------------------------------------------------------------------------- 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 (February 9, 2014) is 3726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) ** Downref: Normative reference to an Informational RFC: RFC 4949 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Alkemade 3 Internet-Draft February 9, 2014 4 Updates: 6120 (if approved) 5 Intended status: Standards Track 6 Expires: August 13, 2014 8 Validating Info/Query (IQ) stanzas in the Extensible Messaging and 9 Presence Protocol (XMPP) 10 draft-alkemade-xmpp-iq-validation-00 12 Abstract 14 This document provides security recommendations for the validation 15 and generation of Info/Query (IQ) stanzas in the Extensible Messaging 16 and Presence Protocol (XMPP). This document updates RFC 6120. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 13, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. No 'from' . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Rejecting spoofed replies to queries . . . . . . . . . . . 4 58 4.3. Preventing presence leaks . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] uses 67 Info/Query (IQ) stanzas as a "request-response" mechanism. The 68 semantics of IQ enable an entity to make a request of, and receive a 69 response from, another entity. The interaction is tracked by the 70 requesting entity through use of the 'id' attribute. Thus, IQ 71 interactions follow a common pattern of structured data exchange such 72 as get/result or set/result (although an error can be returned in 73 reply to a request if appropriate). 75 However, it was found not all implementations properly verify the 76 origin of IQ responses. This documents provides recommendations on 77 how to avoid spoofed responses. 79 2. Terminology 81 Various security-related terms are to be understood in the sense 82 defined in [RFC4949]. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 [RFC2119]. 89 3. Discussion Venue 91 The discussion venue for this document is the mailing list of the 92 XMPP Working Group, for which archives and subscription information 93 can be found at . 95 4. Recommendations 97 4.1. No 'from' 99 Section 8.1.2.1. of [RFC6120] specifies that IQ stanzas sent on 100 behalf of the user's own account MUST either (a) include no 'from' 101 attribute or (b) use the user's bare JID as 'from' address (i.e., 102 ). For compatibility with incorrect servers 103 and servers still following [RFC3920], implementations MAY 104 additionally accept a reply with either (a) a 'from' address equal to 105 the full JID of the client (i.e., 106 ) or (b) a 'from' address equal to 107 the domainpart of the JID of the account (i.e., ). 109 4.2. Rejecting spoofed replies to queries 111 'id' attributes are used as end-to-end identifiers of stanzas: the 112 same 'id' attribute is used across every hop. When delivered, the 113 receiver will see the same 'id' value as the sender specified. As 114 described in Section 8.1.3. of [RFC6120], it is REQUIRED to include 115 'id' values on IQ stanzas and RECOMMENDED for all other stanza types. 116 The entity creating a stanza needs to ensure the 'id' values it 117 generates are unique. 119 After sending an IQ stanza with type "get" or "set", an entity may 120 store the 'id' and 'to' of the outgoing element to identify the 121 response. When an IQ stanza comes in with a matching 'id' and type 122 "result" or "error", the entity MUST verify that the 'from' attribute 123 on the matches the 'to' of the outgoing stanza. If the 'from' 124 and 'to' attributes do not match, the entity MUST ignore the stanza. 125 As is mandatory in response to IQ stanzas of type "result" or 126 "error", the entity MUST NOT return an error. 128 For queries where the intended recipient is the server acting on 129 behalf of the user's own account entities MAY apply the exceptions in 130 Section 4.1. 132 4.3. Preventing presence leaks 134 Many implementations use a counter to generate new 'id' attributes 135 for stanzas to guarantee their uniqueness. However, this may leak 136 presence information of the user: it can give an approximation of how 137 long a client has been running and how many stanzas it has sent since 138 a previous stanza. This could, for example, give an indication of 139 how many messages a user has sent in a certain time. Therefore 140 clients SHOULD NOT include a counter in the 'id' attribute. 142 Additionally, it is RECOMMENDED to use randomly or pseudo-randomly 143 generated 'id' attributes. Implementations using [RFC4122] to 144 generate Universally Unique IDentifiers (UUIDs) to use as 'id' 145 attributes MUST use version 4 UUIDs, which are randomly or pseudo- 146 randomly generated and carry no identifying information. 147 Implementations using a pseudo-random generator, either directly or 148 for generating UUIDs, SHOULD make sure that future values are hard to 149 predict. For more information see [RFC4086]. 151 5. IANA Considerations 153 This document requests no actions of the IANA. 155 6. Security Considerations 157 This document covers security. 159 7. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 165 Protocol (XMPP): Core", RFC 3920, October 2004. 167 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 168 Requirements for Security", BCP 106, RFC 4086, June 2005. 170 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 171 Unique IDentifier (UUID) URN Namespace", RFC 4122, 172 July 2005. 174 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 175 RFC 4949, August 2007. 177 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 178 Protocol (XMPP): Core", RFC 6120, March 2011. 180 Author's Address 182 Thijs Alkemade 184 Email: me@thijsalkema.de