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

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

On 2/7/14, 7:37 AM, Ben Laurie wrote:
> 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.

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/