Subject: [xmpp] 3921bis: security note about roster pushes

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 10:58:04 +0800

During discussions in Beijing, Joe Hildebrand mentioned to me that we're
missing a security note in 3921bis about client handling of roster
pushes, which might come from entities other than the server now that
we've removed special-casing of roster information by the server.
Therefore I propose adding the following note to Section 2.1.6 of 3920bis:

      Security Note: 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).

/psa

---

From: Paul Aurich <[email-masked]>
Date: Thu, 11 Nov 2010 21:20:51 -0800

> Therefore I propose adding the following note to Section 2.1.6 of 3920bis:

3921bis, I hope :)

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

Seems reasonable to me.

~Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 13:26:05 +0800

>> Therefore I propose adding the following note to Section 2.1.6 of 3920bis:

Yes. Too much multitasking...

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

Thanks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: luca tagliaferri <[email-masked]>
Date: Fri, 12 Nov 2010 16:12:32 +0100

Hi,

actually in Bluendo we are dealing with distributed rosters and hence
we are facing similar problems.

Actually we are using an xmpp2xmpp gateway that stores a remote roster
for connected client

We mapped the presence subscription stanzas with iq packets so that the
component and the server

do not interfere with each other when a new jid is added to the remote
roster

We added two new states for the subscription like in the following
stanzas:

This iq is sent when a user ask to subscribe to the contact presence

<iq from='xmpp2xmpp.jabber.bluendo.com'
to=[email-masked]/lampiro' type='set'
id='150'>

<query
xmlns=’jabber:iq:roster#new’>

<item
jid='hecate\[email-masked]'
subscription='ask'/>

<query>

</iq>

This one instead is sent by the client that wished to add a new contact
to its roster

<iq
from=[email-masked]/lampiro'
to='xmpp2xmpp.jabber.bluendo.com' type='set' id='130' >

<query
xmlns=’jabber:iq:roster#new’>

<item
jid='hecate\[email-masked]'
subscription='add'/>

<query>

</iq>

Il 12/11/2010 06:26, Peter Saint-Andre ha scritto:

3921bis, I hope :)

/psa

Seems reasonable to me.

Thanks.

Peter

_______________________________________________
xmpp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xmpp

---

From: Luca Tagliaferri <[email-masked]>
Date: Mon, 15 Nov 2010 16:13:37 +0100

Hi,

I would like to underline that such an approach is meant to replace the
usual presence subscription packages

when dealing with distributed rosters

Any comment to this approach?

Would it be a feasible way to follow?

Il 12/11/2010 16:12, luca tagliaferri ha scritto:

Hi,

to=[email-masked]/lampiro'
type='set'

id='150'>

<query

<item

subscription='ask'/>

<query>

</iq>

to its roster

<iq

<query

<item

subscription='add'/>

<query>

</iq>

3921bis, I hope :)

/psa

Seems reasonable to me.

Thanks.

Peter