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

Ben Laurie <benl@google.com> Thu, 06 February 2014 18:16 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD01A0432 for <secdir@ietfa.amsl.com>; Thu, 6 Feb 2014 10:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level:
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0FTixiNd_Tx for <secdir@ietfa.amsl.com>; Thu, 6 Feb 2014 10:16:47 -0800 (PST)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 566DE1A0454 for <secdir@ietf.org>; Thu, 6 Feb 2014 10:16:45 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so1805096veb.16 for <secdir@ietf.org>; Thu, 06 Feb 2014 10:16:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DC9KquvgCzHRzNuqVY+ClEjpC8jNLJTxacXxGQck5FM=; b=l199ph8FQeEdUVE7taQh09bSbGa80FgN0Uk2FReYmxhWtFNB3YSHjJylBcaH8N6Azn 4NtiC9r8SUK6uXkeWdCevjchRdK8bdHf/9tfizFrQ1JtS2YmNVRC3kiW3bjOFsvq20at S2d0H3693FxCm91ddlEppJkKqCc6SfspjP5wL3DSNQMs2+mXkVB5np6s2cM3XnLdrpRM bbW9kysaIxUVyoNTiH1ZmcbakYrD6+wvzLYFDXuvLREK+2pPR464NgXoH5/Vo+Rm+kHp adg/ixk9H0XOTqrxI9dbgZtp9mFiymxll6OOAbECrB5YjaLszobyX5LGhvSUpkJ2g9V6 NSgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DC9KquvgCzHRzNuqVY+ClEjpC8jNLJTxacXxGQck5FM=; b=JGtTnSW/xkLG8JiDVzA/vP6N6rGV0p1lxU8bAMQ+/IBY8hxL4PaWcShXTQqyPkkfXd K1akzbBBLJuUJ/TbEuQ483+RatmQDbukYvw0G01hnhLggY0+a5KWP9E3FgTjWRjE+AiA sLrrw7u26GBi5pKYCpqwXItngH0IrUt+Kwppm8h/f77/4JkNQxRMwKOl7BwTgQrG0UHa P1BBpF6KblmVWU7zYXj3ckL19nJ+tDgLvspDUjEablfLJNZDJ10HaIA5CE2QSzyfJAXN XVFxBhySy1ppeHTqjRXSBairZ+kiOek77daOJvh60dME0fNRE9uczJGOmdkhtYW+XMHz Hrng==
X-Gm-Message-State: ALoCoQl70xLDiNdtfduUWP7AiFcbN0Yw1uP9r2R0AOe7lHmH30iLXYFo7Kkzt43XitNSJoUm6dCEfTbQx3BMZEM0u+S7Iwy4KjpO7Ph45i842g43kEiqPwKSggh5zhRIru7KQk52xX4Mkdf5FeqBqVDG0USzaXCMlgQDuFSwGyHNXIFPDacHYMM5m0iFZe4lmu66aBznzPIa
MIME-Version: 1.0
X-Received: by 10.220.48.194 with SMTP id s2mr363157vcf.43.1391710603815; Thu, 06 Feb 2014 10:16:43 -0800 (PST)
Received: by 10.52.230.105 with HTTP; Thu, 6 Feb 2014 10:16:43 -0800 (PST)
In-Reply-To: <52F2D09C.8000900@stpeter.im>
References: <CABrd9SQ7EV5hZ-cEP3DLsBTN5WAwxUFpxndX=iUXzhJ68fu-6A@mail.gmail.com> <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im>
Date: Thu, 6 Feb 2014 18:16:43 +0000
Message-ID: <CABrd9SQr+-XTKDAw5O65doHYiQHw+FSGXLDnED2AZ7dzWzwxLw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Cc: The IESG <iesg@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 18:16:50 -0000

On 6 February 2014 00:00, Peter Saint-Andre <stpeter@stpeter.im>; 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" (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 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" (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/