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

[Ben Laurie <[e-mail]>]

On 7 February 2014 03:44, Peter Saint-Andre <[e-mail]> wrote:
> 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.

Sounds good to me.

>
> Peter
>