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

[Lance Stout <[e-mail]>]

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


—Lance