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

Lance Stout <> Wed, 30 April 2014 05:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 201141A212D for <>; Tue, 29 Apr 2014 22:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o6bisNgDrHMi for <>; Tue, 29 Apr 2014 22:06:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F300C1A1F16 for <>; Tue, 29 Apr 2014 22:06:49 -0700 (PDT)
Received: by with SMTP id v10so1159360pde.13 for <>; Tue, 29 Apr 2014 22:06:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ABWwhRPfSy3N0jJRhvOIBPtd1edVJorIimwXAb+MNzc=; b=ldNslwHHRMJPnjA1OXNPpViZ5+kQuMw+J7TO6TJqhMxZihiomGTZ5rFuBFPUjrZfeV UoQoSCljGidEtmOYln1FgOHexylmpgbrUOBIBVx8GissiAk+xJWq7f6MFFAHWMzyWlYI qEC0dU7G3O99styUuXufKbJ89B/cuwb00ONyHFZbH4Lbu1ibU9/FPg85wQEMcWqPtxsh mQX1lxSqe4CLKTX9jY2i+rzUQ4nyuqwmTOSHszhiUk50y7kHz+jZowZqNrBYKazUGqG3 GWtqjGAFfYYAt4dQZyzKbJ7jXw3vsAdKFt5O1MVJ/WMZxTHobsbssS5AooIv+U9h1obs MrIw==
X-Gm-Message-State: ALoCoQkC0mXL+7sAybWb49rO6WsyyMqi0ou9+Njui4bJ7Q/2BBXdi84VK7tW4KrFA/34RSCKM3Z8
X-Received: by with SMTP id y9mr4152359pas.145.1398834407995; Tue, 29 Apr 2014 22:06:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id xg8sm126674194pac.26.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 22:06:46 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_F23A65A5-DE4C-4B5A-B7E1-10EA1245B316"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Lance Stout <>
In-Reply-To: <>
Date: Tue, 29 Apr 2014 22:06:41 -0700
Message-Id: <>
References: <> <> <> <>
To: XMPP Working Group <>
X-Mailer: Apple Mail (2.1874)
Cc: Ben Campbell <>
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Apr 2014 05:06:53 -0000

> 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


> 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.

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.