Subject: [xmpp] Roster Protection on Server?

From: Sean Turner <[email-masked]>
Date: Sun, 21 Jun 2009 16:43:26 -0400

In reading draft-ietf-xmpp-3921bis-00.txt, I'm curious why there are no 
requirements to protect the roster that's stored on the server.  Was 
this discussed previously and determined to be out of scope?

spt

---

From: Jack Moffitt <[email-masked]>
Date: Sun, 21 Jun 2009 14:54:31 -0600

> requirements to protect the roster that's stored on the server.  Was this
> discussed previously and determined to be out of scope?

Protect from what?  We'll need an appropriate threat model before we
can address it.

jack.

---

From: Joe Hildebrand <[email-masked]>
Date: Sun, 21 Jun 2009 21:43:07 -0600

It may be that section 2.1.3 needs another rule, that servers SHOULD ignore
changes sent from other accounts; that's pretty obvious in our world, but
it's worth writing down.  I'd say SHOULD with the caveat that there may be
authorized 3rd parties that can change a roster (with that authorization out
of scope of this document).  Of course, there should be a not-allowed or
not-authorized error returned in this case.

On 6/21/09 2:54 PM, "Jack Moffitt" <[email-masked]> wrote:

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

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Mon, 22 Jun 2009 09:12:09 +0100

On Sun Jun 21 21:43:26 2009, Sean Turner wrote:
> In reading draft-ietf-xmpp-3921bis-00.txt, I'm curious why there  
> are no requirements to protect the roster that's stored on the  
> server.  Was this discussed previously and determined to be out of  
> scope?

I'm with Jack on this one. I think at best it's worth addressing in  
the Security Considerations; viz. "The user's roster can contain  
confidential data, and access to this data must be suitably  
restricted to the user, and, potentially, authorized third parties."

Might be worthwhile adding a pointer there to XMPP-CORE section  
15.11, but that in itself needs additional text to note that from the  
perspective of example.net, there's no method for distinguishing  
between [email-masked] and [email-masked]. (ie, with foreign  
domains, only the domain can be authorized with assurance).

While I'm here, as it were, the fourth bullet in XMPP-IM's Section 11  
is largely the same thing as XMPP-CORE's 15.15 - I think some  
consolidation, and possibly cross-referencing, is in order.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Jun 2009 11:27:54 -0600

> not-authorized error returned in this case.

Why not force an authorized third party to use something like ad-hoc
commands (cf. XEP-0133) to change another person's roster, rather than
overloading jabber:iq:roster? Personally I'd like to change as many
SHOULDs to MUSTs as possible...

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 22 Jun 2009 11:30:52 -0600

> SHOULDs to MUSTs as possible...

Fine.  It was kind of an edge case anyway.

-- 
Joe Hildebrand