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

From: Ben Campbell <[email-masked]>
Date: Mon, 5 May 2014 14:21:23 -0500

(as individual)

On Apr 30, 2014, at 12:06 AM, Lance Stout <[email-masked]> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 May 2014 12:31:04 -0600

On 4/23/14, 1:24 PM, Ben Campbell wrote:
>
> On Apr 22, 2014, at 6:29 PM, Lance Stout <[email-masked]> wrote:
>
>>
>> On Apr 22, 2014, at 2:49 PM, Ben Campbell <[email-masked]> 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