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

Peter Saint-Andre <> Thu, 06 February 2014 18:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5C94B1A03C0; Thu, 6 Feb 2014 10:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LWyRU8yWHyoQ; Thu, 6 Feb 2014 10:56:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B1C1B1A00EA; Thu, 6 Feb 2014 10:56:34 -0800 (PST)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id ADFE64010C; Thu, 6 Feb 2014 11:56:32 -0700 (MST)
Message-ID: <>
Date: Thu, 06 Feb 2014 11:56:31 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ben Laurie <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: The IESG <>,, "" <>
Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Feb 2014 18:56:37 -0000

On 2/6/14, 11:16 AM, Ben Laurie wrote:
> On 6 February 2014 00:00, Peter Saint-Andre <> 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 ought to allow only users within
>>>>      the domain to access the gateway, not users within
>>>>,, 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?
> 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
>>     ought to allow only users within the domain to access the
>>     gateway, not users within,, 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 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.


Peter Saint-Andre