Re: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-10: (with DISCUSS and COMMENT)
Peter Saint-Andre <stpeter@mozilla.com> Tue, 26 March 2019 02:12 UTC
Return-Path: <stpeter@mozilla.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92BF1201E1 for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 19:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALNxY-5LN745 for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4DF1201D9 for <mile@ietf.org>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id 10so7336485pfo.5 for <mile@ietf.org>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sXUQvRJnCre1T8ckKp1GDkGWkYlCPozfqhe+YTfhaFU=; b=EhJKT6u9hzKFDFBtl/RLlBEWeVzEcC/+RfCR6U+I9SVsa0PDojZwB1O4DBAh8FFv7B h/uW79OQxR4gyoyibb36JoBIkuvTomK+rGa4766fZWtZ/0+Xn4H7TDzAWVFERMNdSxmw 7zlFF1+ZRzHPR4oCFtkNxrCXBlaWUgJZ1mlT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sXUQvRJnCre1T8ckKp1GDkGWkYlCPozfqhe+YTfhaFU=; b=YiYWl3odNnBmV6iLRQLy9ZdLFWBPPO81DvQiZikVBmdWULEvLuCp6XmBWWQJha4LfS BgvdsM2X+R52u8uPLcyRkXlSXQYqS6cbfImoSodohQh650TUguPLwLlvK4HkomP3V9gf Mo/IKxSAmKCGGnDv+g902Kt7M/EfcgGRKjbeVZWzoIw5jLAJU695vx0MN5p0Lzpeouco AsfcvuHv032RCl5dBcyPSM56F2aS25++DYTeAALPQ5OWKvZbAjB75ja0DgyxG2mneEOO B2qtKTqgZKuoukDVXRG7SlXoUBhPyMhJtJScMueE5+tsjtH21PYvLHfO5X/iCl99j569 D0FA==
X-Gm-Message-State: APjAAAUDiFVO2MmFKjTCaEGDELTNQc+OtFUzMVwJFafSI6FZpeJTDIx/ 9jAtdfyrRlKfPGqFai0C7+4s+A==
X-Google-Smtp-Source: APXvYqwpDNZDqYLIAvtdBootS/jtDKbsfpDgz4cH3I2Fu8IcVPdVmJzccBtjfY9WwuPF2rysjMxH5Q==
X-Received: by 2002:a63:7117:: with SMTP id m23mr19276618pgc.271.1553566344823; Mon, 25 Mar 2019 19:12:24 -0700 (PDT)
Received: from dragon.local ([74.85.93.170]) by smtp.gmail.com with ESMTPSA id w1sm27119321pfb.164.2019.03.25.19.12.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 19:12:24 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile@ietf.org, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org
References: <155355003226.24676.11013184390807731904.idtracker@ietfa.amsl.com>
From: Peter Saint-Andre <stpeter@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <92e77b7d-bf3e-6c27-d614-819295d69fdd@mozilla.com>
Date: Mon, 25 Mar 2019 20:12:20 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <155355003226.24676.11013184390807731904.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/U_e2vr5Po52PUuyYV1AFsiVcUeU>
Subject: Re: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-10: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 02:12:30 -0000
Hi Ben, replies inline. On 3/25/19 3:40 PM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-mile-xmpp-grid-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for updating to describe this document as essentially an RFC206-style > applicability statement; that helps a lot to frame what it is intending to deliver, > and the other updates are improvements as well. > > That said, I think a couple of my DISCUSS points remain applicable: > > Section 8.2.3 still has text about how an XMPP Grid Controller could obtain > XMPP-Grid Platform credentials and impersonate the XMPP Grid Platform > even after the breach of the XMPP Grid Controller is repaired. The current > MTI SASL mechanisms do not give the controller that ability, and it's only > bad mechanisms like PLAIN that involve sending cleartext passwords/bearer > tokens to the server that give an attacker that compromises the controller > this ability. I think we need to clarify that this depends on the SASL mechanism > used, and that the MTI mechanisms are not vulnerable to this attack. Suggested change: > > OLD: > o Obtain and cache XMPP-Grid Platform credentials so they can be > used to impersonate XMPP-Grid Platforms even after a breach of the > XMPP-Grid Controller is repaired > NEW: > o Obtain and cache XMPP-Grid Platform credentials so they can be > used to impersonate XMPP-Grid Platforms even after a breach of the > XMPP-Grid Controller is repaired. Some SASL mechanisms (including > the mandatory-to-implement SCRAM and EXTERNAL with TLS mutual > certificate-based authentication) do not admit this class of attack, but > others (such as PLAIN) are susceptible. Yes, that's better. > The secdir review notes that the full implications of the > participants' access to plaintext data are not covered. (This also relates > to Ben's discuss point (2).) For the avoidance of doubt, in a note earlier today I proposed adding a new subsection under "Countermeasures" in the security consdierations: 8.3.6. End-to-End Encryption of Messages Because it is expected that there will be a relatively large number of Consumers for every Topic, for purposes of content discovery and scaling this document specifies a "one-to-many" communications pattern using the XMPP Publish-Subscribe extension. Unfortunately, there is no standardized technology for end-to-end encryption of one- to-many messages in XMPP. This implies that messages can be subject to eavesdropping, data injection, and data modification attacks within a Broker or Controller. If it is necessary to mitigate against such attacks, implementers would need to select a messaging pattern other than [XEP-0060], most likely the basic "instant messaging" pattern specified in [RFC6121] with a suitable XMPP extension for end-to-end encryption (such as [RFC3923] or a more modern method such as [XEP-0384]). The description of such an approach is out of scope for this document. > Some of them are covered by existing text, > e.g., the trust model's instistence that the platforms preserve the > confidentiality of sensitive data, but others are not. I repeat here the > portions of the COMMENT section that seem relevant: > > Section 8.1.3 > > The controller is also trusted to preserve the integrity (and > confidentiality against unauthorized parties) of the data flowing through > it. > > Section 8.2.2 > > The authorized platform could advertise data that is incorrect with the > intent to lead to incorrect actions by the recipients, without needing to > exploit vulnerabilities in other systems or compromising them. > > Suggested additions: > > Section 8.1.3: > > o Preserve the integrity (and confidentiality against unauthorized parties) > of the data flowing through it. > > Section 8.2.2 > > Advertise false data that leads to incorrect (e.g., potentially attacker-controlled > or -induced) behavior of XMPP-Grid Platforms, by virtue of applying correct procdeures > to the falsified input. Thanks for the suggested improvements, we'll incorporate those. I'll also look more closely at your comments (below), since I'm sorry to say that I didn't do so earlier. Peter > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > In the vein of Alissa's comments, I think this section is missing a > high-level technical view, perhaps something like: > > The XMPP Grid does not introduce any new protocols or technologies, but > rather describes a scheme by which XMPP pubsub functionality is used to > quickly and efficiently distribute information relating to security > incidents and their detection, potentially scaling to 100,000s of > subscribers. XMPP service discovery allows for entities to learn about > content distributed via the XMPP Grid via the registered "pubsub#type" > identifiers, which also indicate the format of the data being distributed. > > It could also benefit from some more text placing this tool within the > broader MILE scope. > > Section 4 > > The Platform in item (a) is only listed as having a source of security > data, in which case I would expect the "typical" workflow to only involve > it needing to publish, and not necessarily to subscribe or query. While I > recognize that a typical workflow will include both publishing and > subscribing, it may be worth mentioning that this Platform also desires to > receive some information as well as having a source for it. > > Section 5 > > The Broker responds with the "disco#info" description, which SHOULD > include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field > that specifies the supported namespace (in this example, the IODEF > namespace defined in [RFC7970]): > > Isn't this more of a "the MILE XMPP grid won't work at all if you don't > include a pubsub#type field that indicates iodef payloads"? I could see > doing this as descriptive text about what happens, or as a MUST, but the > SHOULD just doesn't seem right. > > Section 8 > > An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid > Platforms such as Enforcement Points, Policy Servers, CMDBs, and > Sensors, using a publish-subscribe-search model of information > exchange and lookup. [...] > > This jumps in quite quickly, using these terms that have not previously > been defined and are part of a broader architecture that is not directly > relevant to understanding this protocol. Is it necessary to mention them > just in passing like this without other discussion? > > Section 8.1.3 > > The controller is also trusted to preserve the integrity (and > confidentiality against unauthorized parties) of the data flowing through > it. > > Section 8.2.2 > > The authorized platform could advertise data that is incorrect with the > intent to lead to incorrect actions by the recipients, without needing to > exploit vulnerabilities in other systems or compromising them. > > Section 8.2.3 > > o Mount an even more effective denial of service attack than a > single XMPP-Grid Platform could > > There seem to be a number of ways in which the DoS effectiveness could be > increased by a controller (compared to a platform), whether by inducing the > many platforms to perform the same operation in an amplification-style > attack, completely refusing to pass any traffic at all, sending floods of > traffic to (certain) platforms or other targets, or otherwise. Do we care > to make a distinction among them, or is that not helpful at this level of > granularity? > > o Obtain and cache XMPP-Grid Platform credentials so they can be > used to impersonate XMPP-Grid Platforms even after a breach of the > XMPP-Grid Controller is repaired > > This would require that platforms are using things like SASL PLAIN > authentication, and would not be possible if TLS mutual authentication or > some other proof-of-possession-based authentication scheme is used for > client authentication and authorization. It seems important to reiterate > this distinction and point out the risks inherent in transmitting passwords > to the remote party for verification. > > Furthermore, since Section 8.3.1 instructs us that we can only use SASL > EXTERNAL or SCRAM, this sort of credential scraping would only occur if the > EXTERNAL mechanism used permits it (which I believe to be somewhat > unlikely), or if clients were misconfigured to allow non-permitted SASL > mechanisms (which is, unfortunately, fairly likely to be the case > somewhere). This behavior, particularly the risk of client > misconfiguration, should be called out somewhere in the security > considerations. > > o Obtain and cache XMPP-Grid Controller administrator credentials so > they can be used to regain control of the XMPP-Grid Controller > after the breach of the XMPP-Grid Controller is repaired > > (This also requires the use of non-proof-of-possession authentication > schemes.) > > Section 8.3.1 > > be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in > [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST > > Citing RFC 8446 (TLS 1.3) for TLS 1.2 is rather strange. > > The selection of which XMPP-Grid Platform > authentication technique to use in any particular deployment is left > to the administrator. > > But from a very short list of options! Why do we need to prevent the usage > of other, equally secure, SASL mechanisms, for example, all the GSS-API > mechanisms available via GS2 bridging? > > Section 8.3.2 > > The XMPP-Grid > Controller MAY provide functional templates so that the administrator > can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] > server and authorize only the operations and metadata types needed by > a DHCP server to be permitted for that XMPP-Grid Platform. [...] > > Why is DHCP so privilged to be the only application protocol called out > explicitly here? It seems that this is just an example and the same > profiling/resterictions could be applied for any application protocol. > > unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD > make it easy to revoke an XMPP-Grid Platform's authorization when > > I don't think "SHOULD make it easy" is particularly actionable for > a normative requirement. Similarly for "SHOULD be hardened" in the next > paragraph. > > Section 8.3.3 > > Administrators SHOULD NOT use password-based > authentication but should instead use non-reusable credentials and > multi-factor authentication (where available). [...] > > [see previous remarks about permitted SASL mechanisms] > > Section 8.3.5 > > While XMPP-Grid is designed for high scalability to 100,000s of > Platforms, [...] > > Where is this documented? > > Section 8.3.6 > > nit?: I would not really describe CT as a "guideline for proper CA > security", but rather a tool for discovering failures to maintain proper CA > security. > > I think we need to be careful about recommending pinning, since it > introduces a new DoS vector when there is a legitimate need to change > certificates. If we're talking about pinning, we would presumably also > want to recommend against pinning EE certificates and only intermediate or > root CAs, and to have monitoring for imminent expiration events. > > Section 9 > > Another consideration for deployers is to enable end-to-end > encryption to ensure the data is protected from the data layer to > data layer and thus protect it from the transport layer. > > It's probably worth a(nother?) reminder that the mechanisms for doing so > are out of scope for this document. > >
- [mile] Benjamin Kaduk's Discuss on draft-ietf-mil… Benjamin Kaduk via Datatracker
- Re: [mile] Benjamin Kaduk's Discuss on draft-ietf… Peter Saint-Andre