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

(as individual)

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