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" (user@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?
>
> 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?

    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" (user@domain.tld) 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/