Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02

Ben Campbell <ben@nostrum.com> Mon, 05 May 2014 19:21 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA2D1A045C for <xmpp@ietfa.amsl.com>; Mon, 5 May 2014 12:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 Gjm3P8CLFpCk for <xmpp@ietfa.amsl.com>; Mon, 5 May 2014 12:21:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBFC1A0458 for <xmpp@ietf.org>; Mon, 5 May 2014 12:21:32 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s45JLNLJ096081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 May 2014 14:21:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <E6455E61-FF82-417A-B6E3-09E455FFDDB4@andyet.net>
Date: Mon, 5 May 2014 14:21:23 -0500
X-Mao-Original-Outgoing-Id: 421010483.499753-2708597c7adba04cdd907dd1dde96ddf
Content-Transfer-Encoding: quoted-printable
Message-Id: <28BBC9A1-88FE-4D0D-9DCF-327D5B80B76C@nostrum.com>
References: <F8275190-9346-4879-9843-A3DF6C604F8C@nostrum.com> <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <E6455E61-FF82-417A-B6E3-09E455FFDDB4@andyet.net>
To: Lance Stout <lance@andyet.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/dODNif8MqYiNat8HIS7sobHDBBY
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 19:21:37 -0000

(as individual)

On Apr 30, 2014, at 12:06 AM, Lance Stout <lance@andyet.net> wrote:

>> If an XMPP implementation, especially a server, is behind a connection manager, is it aware of that fact?
> 
> No. It is either aware because the two were configured in tandem within the same administrative context, or it sees what appear to be standard TCP C2S sessions.
> 
>> Is it assumed to implement this draft? Are we requiring special behavior of the server, without the server knowing it needs to do it?
> 
> It is not assumed that the server does anything special to facilitate using this draft. In that case a CM would need to translate the TCP C2S session to this draft.
> 
>> If the answer is yes, then I may have concerns in two areas:
>> 
>> 1) Is the connection manager expected to "adapt" server behavior to follow this draft?
> 
> If the target server does not support this draft natively, then a CM will have to:
> 
> 1. Translate the <open/> and <close/> elements back and forth from <stream:stream />
> 2. Emit <close/> elements with see-other-uri values, as needed by the CM
> 3. For any other terminal CM condition, emit the corresponding traditional stream error (NOTE: This case is not mentioned in the draft)
> 4. Marshal all other stanzas and top level elements in and out of WebSocket message frames
> 
> 

It would be helpful to have some comments in the draft to those effects. It's probably not necessary to specify behavior of connection managers, but it would be good to at least mention that we assume that, if a connection manager is present, that the xmpp server does not implement this spec in any way.

OTOH, do we really need mention of connection managers at all?

> 
>> 2) What is the impact of adding a new TLS intermediary, when the server expects a direct SA with the client? Your comment above _might_ be sufficient, but is there any plain vanilla XMPP server behavior and/or security assumptions that break down? Any concerns from a SASL perspective?
> 
> I'm not aware of any new difficulties here; the same situations exist for BOSH already. A server that expects to use mechanisms which assume no intermediaries will fail (as designed!) when put behind a CM that can not share such information with the server. So SCRAM-SHA-1-PLUS will fail, as well as EXTERNAL with client certs. Note that we aren't able to use SCRAM-SHA-1-PLUS in the browser anyway, as we can't access channel binding information.

Those types of things should be mentioned in the security considerations. Even if these considerations already exist for BOSH, they may be new from an IETF perspective. 

IMO (again as an individual), I think the xmpp/websocket draft should mention any known security related difference from plain "vanilla" xmpp.

> 
> I can imagine for large deployments, the CM could contain the authentication logic, passing on a trusted authenticated stream to the main XMPP server for routing. In which case, the CM is again transparent to the user and acts purely as part of a larger, logical XMPP server.

Doesn't that imply an XMPP server that _is_ aware of connection managers? Would you assume such a server was always behind a CM? If not, how would it know when it needed to authenticate vs when a CM had already done so?

> 
> 
> —Lance