powered by Jive Software

Compatibility with legacy servers and RFC 3921

Hi

There were some users (of Jitsi) who complained that they can’t connect to their Cisco Jabber server anymore ([1,2]). This is caused by properly following RFC 6121, 2.1.6 since SMACK-538. However as also mentioned in that issue, some servers send the full JID, which was allowed in RFC 3921, 7.2.

What is your stance on keeping backwards compatibility a) in general, and b) in this case?

Thanks,

Ingo

[1] Update Smack to 4.2 · Issue #306 · jitsi/jitsi · GitHub

[2] Roster problem with Cisco IM&P servers since 2.8 · Issue #362 · jitsi/jitsi · GitHub

What is your stance on keeping backwards compatibility a) in general, and b) in this case?
Well, a) is always nice to have. :slight_smile:

In this particular case we are dealing with a security sensitive aspect. As the Security Warning in RFC 6121 § 2.1.6 states

Security Warning: Traditionally, a roster push included no ‘from’

address, with the result that all roster pushes were sent

implicitly from the bare JID of the account itself. However, this

specification allows entities other than the user’s server to

maintain roster information, which means that a roster push might

include a ‘from’ address other than the bare JID of the user’s

account. Therefore, the client MUST check the ‘from’ address to

verify that the sender of the roster push is authorized to update

the roster. If the client receives a roster push from an

unauthorized entity, it MUST NOT process the pushed data; in

addition, the client can either return a stanza error of <service-

unavailable/> error or refuse to return a stanza error at all (the

latter behavior overrides a MUST-level requirement from

[XMPP-CORE] for the purpose of preventing a presence leak).

So you only want to accept roster pushes from authorized entities. In most XMPP setups, this is the client’s server, although it was so designed that your roster could be hosted by a different entity (I’m not aware of any implementation of this).

Funny enough, this Security Warning contradicts RFC 6121 § 2.1.6 2.

A receiving client MUST ignore the stanza unless it has no ‘from’

attribute (i.e., implicitly from the bare JID of the user’s

account) or it has a ‘from’ attribute whose value matches the

user’s bare JID user@domainpart.

I could however image that we add a whitelist mechanism to Smack’s roster API, where authorized entities can be configured.

I’m not sure how helpful this whitelist API would be for Cisco’s Jabber server, which, if I understood correctly, sends roster pushes from the full JID of the current account. This means that you would need to whitelist that full JID always after resource binding. Appears to be a little cumbersome.

In the end, the only correct solution is to fix Cisco Jabber server.

Funny enough, this Security Warning contradicts RFC 6121 § 2.1.6 2.

Reported as Errata: RFC Errata Report » RFC Editor #5058

Thanks, Flow. I realize this is security relevant and I also agree that Cisco should fix their server, but I guess we both know the likelyhood of this to happen.

Please forgive my lack of deeper XMPP knowledge, but how would allowing the full JID sending roster pushes compromise the security (of course not any full JID, but just the one of the current connection)?

Please forgive my lack of deeper XMPP knowledge, but how would allowing the full JID sending roster pushes compromise the security (of course not any full JID, but just the one of the current connection)?
I don’t think it would compromise the security.

It just didn’t came to my mind that this is what you proposing. :wink:

I’ve created [SMACK-773] Allow roster pushes from our full JID for backwards compability - IgniteRealtime JIRA

Ah well, I guess I should make clearer proposals next time :slight_smile:

I’ve created PR#150 on Github.