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

[Ben Laurie <[e-mail]>]

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?

> 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
>
> --
> Peter Saint-Andre
> https://stpeter.im/