Subject: [secdir] sec-dir review of draft-ietf-stox-presence-07

From: Ben Laurie <[email-masked]>
Date: Mon, 3 Feb 2014 17:50:25 +0000

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 simple.example.com ought to allow only users within
   the example.com domain to access the gateway, not users within
   example.org, example.net, 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" ([email-masked]) 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?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Feb 2014 20:11:29 -0700

Hi Ben, thanks for the review. Comments inline.

On 2/3/14, 10:50 AM, Ben Laurie wrote:
> defence at all in that case.

Don't allow open registration. :-)

Further, I think it would be irresponsible to offer a generalized 
gateway for use by any domain, so the foregoing text might be misleading.

> Perhaps some kind of rate limitation
> would be useful?

All self-respecting XMPP servers include rate limiting, but it's unclear 
whether that would really help much in practice since you don't any sort 
of amplification in order to attack users at another domain even in the 
absence of a gateway (just normal XMPP server-to-server will do).

> is unclear: how does it help?

This check at least places a burden on the XMPP server itself and 
verifies if the XMPP user has an active presence session before updating 
the presence subscription on the SIP side of the gateway.

I'll think about the matter more deeply and formulate some better text.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Feb 2014 17:00:28 -0700

> I'll think about the matter more deeply and formulate some better text.

How is this?

    The mismatch between long-lived XMPP presence subscriptions and
    short-lived SIP presence subscriptions introduces the possibility of
    an amplification attack launched from the XMPP network against a SIP
    presence server (since each long-lived XMPP presence subscription
    would typically result in multiple subscription refresh requests on
    the SIP side of a gateway).  Therefore, access to an XMPP-SIP gateway
    SHOULD be restricted in various ways; among other things, only an
    XMPP service that carefully controls account provisioning ought to
    host such a gateway (e.g., not a service that offers open account
    registration) and a gateway ought to be associated only with a single
    domain or trust realm (e.g., a gateway hosted at simple.example.com
    ought to allow only users within the example.com domain to access the
    gateway, not users within example.org, example.net, or any other
    domain).  If a SIP presence server receives communications through an
    XMPP-SIP gateway from users who are not associated with a domain that
    is so related to the hostname of the gateway, it SHOULD (based on
    local service provisioning) refuse to service such users or refuse to
    receive traffic from with the gateway.  As a futher check, 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" ([email-masked]) of the XMPP user, to which the
    user's XMPP server MUST respond in accordance with [RFC6121]; this
    puts an equal burden on the XMPP server as on the SIP server.

Peter

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Feb 2014 18:16:43 +0000

>> I'll think about the matter more deeply and formulate some better text.

Better, but...

>    domain).

...I suspect the criterion you are really trying to capture is that
their should be some kind of administrative link between the XMPP
server and its users (i.e. abusers can be permanently kicked off, if
needed). Perhaps better to say that directly?

> If a SIP presence server receives communications through an

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Feb 2014 11:56:31 -0700

> needed). Perhaps better to say that directly?

Yes, that's part of it but not all of it. For instance, I run the 
jabber.org IM service, which has 1.4 million users or so. The other 
admins and I definitely have the ability to permanently disable user 
accounts, we have user registration locked down, we have rate limiting 
in place, etc. -- but there's no way we'd ever offer a gateway of the 
kind described in this document because we have too many users to know 
them all or have any truly effective control over them. If I were 
running an XMPP service at a company (even a company with 100,000 
employees) I'd be comfortable offering a gateway, because the company 
could always fire someone who does something wrong.

I'll try again to rework the text to capture some of these ideas.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Feb 2014 20:44:11 -0700

> I'll try again to rework the text to capture some of these ideas.

A further text tweak:

   The mismatch between long-lived XMPP presence subscriptions and
   short-lived SIP presence subscriptions introduces the possibility of
   an amplification attack launched from the XMPP network against a SIP
   presence server (since each long-lived XMPP presence subscription
   would typically result in multiple subscription refresh requests on
   the SIP side of a gateway).  Therefore, access to an XMPP-SIP gateway
   SHOULD be restricted in various ways; among other things, only an
   XMPP service that carefully controls account provisioning and
   provides effective methods for the administrators to control the
   behavior of registered users ought to host such a gateway (e.g., not
   a service that offers open account registration) and a gateway ought
   to be associated only with a single domain or trust realm (e.g., a
   gateway hosted at simple.example.com ought to allow only users within
   the example.com domain to access the gateway, not users within
   example.org, example.net, or any other domain).  If a SIP presence
   server receives communications through an XMPP-SIP gateway from users
   who are not associated with a domain that is so related to the
   hostname of the gateway, it SHOULD (based on local service
   provisioning) refuse to service such users or refuse to receive
   traffic from with the gateway.  As a futher check, 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" ([email-masked]) of the XMPP user, to which the user's XMPP
   server MUST respond in accordance with [RFC6121]; this puts an equal
   burden on the XMPP server as on the SIP server.

Peter

---

From: Ben Laurie <[email-masked]>
Date: Fri, 7 Feb 2014 14:37:26 +0000

>    burden on the XMPP server as on the SIP server.

Sounds good to me.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 07 Feb 2014 07:45:35 -0700

>>     burden on the XMPP server as on the SIP server.

Great. As soon as Pete tells me he likes the other changes I made to 
address the issues he raised in his DISCUSS, I'll submit a revised I-D.

Peter

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