Skip to main content

Last Call Review of draft-ietf-stox-presence-06

Request Review of draft-ietf-stox-presence
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-02-04
Requested 2013-11-28
Authors Peter Saint-Andre , Avshalom Houri , Joe Hildebrand
Draft last updated 2014-02-06
Completed reviews Genart Last Call review of -06 by Joel M. Halpern (diff)
Genart Telechat review of -07 by Joel M. Halpern (diff)
Secdir Last Call review of -06 by Ben Laurie (diff)
Assignment Reviewer Ben Laurie
State Completed
Review review-ietf-stox-presence-06-secdir-lc-laurie-2014-02-06
Reviewed revision 06 (document currently at 09)
Result Has Nits
Completed 2014-02-06
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: ready with nits

Detail: the I-D documents a mapping between two fairly well-matched
presence protocols, and hence does not introduce much danger. The one
area of concern is that SIP presence subscriptions are short-lived and
XMPP's are long-lived, thus opening the possibility of an
amplification attack against SIP via XMPP.

The suggested mitigation is weak:

"To help prevent such an attack, access to an XMPP-
   SIP gateway that is hosted on the XMPP network SHOULD be restricted
   to XMPP users associated with a single domain or trust realm (e.g., a
   gateway hosted at ought to allow only users within
   the domain to access the gateway, not users within,, or any other domain)"

Many XMPP servers allow open registration and so this defence is no
defence at all in that case. Perhaps some kind of rate limitation
would be useful?

Also, this part:

"Furthermore, whenever an XMPP-SIP gateway seeks to refresh
   an XMPP user's long-lived subscription to a SIP user's presence, it
   MUST first send an XMPP <presence/> stanza of type "probe" from the
   address of the gateway to the "bare JID" (user at domain.tld) of the
   XMPP user, to which the user's XMPP server MUST respond in accordance
   with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY
   (based on local service provisioning) exempt "known good" XMPP
   servers from this check (e.g., the XMPP server associated with the
   XMPP-SIP gateway as described above)."

is unclear: how does it help?