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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 05 February 2014 03:11 UTC

Return-Path: <stpeter@stpeter.im>
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 7BACC1A000C; Tue, 4 Feb 2014 19:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2xhBZg42wHF; Tue, 4 Feb 2014 19:11:31 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD5961A0013; Tue, 4 Feb 2014 19:11:31 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D51EC4032A; Tue, 4 Feb 2014 20:11:30 -0700 (MST)
Message-ID: <52F1ABE1.4000805@stpeter.im>
Date: Tue, 04 Feb 2014 20:11:29 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
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 <benl@google.com>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org
References: <CABrd9SQ7EV5hZ-cEP3DLsBTN5WAwxUFpxndX=iUXzhJ68fu-6A@mail.gmail.com>
In-Reply-To: <CABrd9SQ7EV5hZ-cEP3DLsBTN5WAwxUFpxndX=iUXzhJ68fu-6A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 05 Feb 2014 03:11:34 -0000

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/