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

[Peter Saint-Andre <[e-mail]>]

On 02/06/2014 11:56 AM, Peter Saint-Andre wrote:
> On 2/6/14, 11:16 AM, Ben Laurie wrote:
>> On 6 February 2014 00:00, Peter Saint-Andre <[e-mail]> wrote:
>>> On 2/4/14, 8:11 PM, Peter Saint-Andre wrote:
>>>>
>>>> Hi Ben, thanks for the review. Comments inline.
>>>>
>>>> On 2/3/14, 10:50 AM, Ben Laurie wrote:
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> 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).
>>>>
>>>>> 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" ([e-mail]) 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?
>>>>
>>>>
>>>> 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.
>>>
>>>
>>> How is this?
>>
>> Better, but...
>>
>>>
>>>     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).
>>
>> ...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?
> 
> 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.

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" ([e-mail]) 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