From nobody Mon May  5 12:21:41 2014
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?
>=20
> 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.
>=20
>> Is it assumed to implement this draft? Are we requiring special =
behavior of the server, without the server knowing it needs to do it?
>=20
> 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.
>=20
>> If the answer is yes, then I may have concerns in two areas:
>>=20
>> 1) Is the connection manager expected to "adapt" server behavior to =
follow this draft?
>=20
> If the target server does not support this draft natively, then a CM =
will have to:
>=20
> 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
>=20
>=20

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?

>=20
>> 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?
>=20
> 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.=20

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

>=20
> 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?

>=20
>=20
> =97Lance


From nobody Tue May 27 11:31:13 2014
Return-Path: <stpeter@stpeter.im>
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 91CA11A05E5 for <xmpp@ietfa.amsl.com>; Tue, 27 May 2014 11:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 XSBXF61m9996 for <xmpp@ietfa.amsl.com>; Tue, 27 May 2014 11:31:08 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C6D001A01F6 for <xmpp@ietf.org>; Tue, 27 May 2014 11:31:08 -0700 (PDT)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EDFFD40C58; Tue, 27 May 2014 12:31:04 -0600 (MDT)
Message-ID: <5384D9E8.5000601@stpeter.im>
Date: Tue, 27 May 2014 12:31:04 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Lance Stout <lance@andyet.net>
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>
In-Reply-To: <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/KXDLM928MoDFVwXvmoagPx5Jtd4
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: Tue, 27 May 2014 18:31:12 -0000

On 4/23/14, 1:24 PM, Ben Campbell wrote:
>
> On Apr 22, 2014, at 6:29 PM, Lance Stout <lance@andyet.net> wrote:
>
>>
>> On Apr 22, 2014, at 2:49 PM, Ben Campbell <ben@nostrum.com> wrote:
>>>
>>> The WGLC has completed. Authors, please let the list know when
>>> you believe all feedback has been addressed. (Note: "addressed"
>>> does not necessarily mean "accepted".)
>>
>> Draft -06 has been published, which I believe addresses all
>> feedback so far.
>>
>>
>> I note there is a pending question on connection managers, but I
>> don't believe that the use of a connection manager affects any of
>> the actions prescribed in the latest document. CMs should be
>> transparent.
>>
>>
>> We do have Security Considerations listed in XEP-0124 for BOSH
>> connection managers, which amount to 'use TLS from the CM to the
>> backend', and 'use e2e encryption on the client' because
>> guaranteeing anything about a CM's behaviour is beyond scope. I can
>> expand the Security Considerations for this document to do the
>> same, if people deem that necessary.
>
> So here's the basis of all of my connection manager questions. This
> may be based on a completely wrong understanding of connection
> managers on my part, so do not hesitate to tell me I am clueless if
> that's the case. :-)
>
> If an XMPP implementation, especially a server, is behind a
> connection manager, is it aware of that fact?

Connection managers are trusted server components, so the administrators 
of the service are aware that there is a CM in the mix, but the server 
need not be (all it knows is that sessions have been created and that 
some trusted entity did so).

> Is it assumed to
> implement this draft?

The server doesn't really need to implement the websocket aspect of 
things, since that's handled by the CM.

> Are we requiring special behavior of the
> server, without the server knowing it needs to do it?

Not as far as I can see.

BTW, I've updated the shepherd write up:

https://stpeter.im/files/writeup-ietf-xmpp-websocket.txt

Peter