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

Ben Laurie <benl@google.com> Fri, 07 February 2014 14:37 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 3A57E1A1EFE for <secdir@ietfa.amsl.com>; Fri, 7 Feb 2014 06:37:31 -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=unavailable
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 lVhe7hl28HxR for <secdir@ietfa.amsl.com>; Fri, 7 Feb 2014 06:37:29 -0800 (PST)
Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7101A1F72 for <secdir@ietf.org>; Fri, 7 Feb 2014 06:37:27 -0800 (PST)
Received: by mail-vb0-f51.google.com with SMTP id 11so2659992vbe.38 for <secdir@ietf.org>; Fri, 07 Feb 2014 06:37:26 -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=esPCyvAWzksjGTIju7EOsBaVxbzbGZwISB0s6mm212w=; b=S+iHzh83ajcM0kyhjN8viwnJB+2VybcqCJxhmpMz0YAEze2u9PYPPLDi4lYZrxm54S IZ05mwNWaiVOaUN8LFwWwe6CinczIlAv6ZZl7vEwNlUjMa8FFA7hQylCOzyZra2hmu9z S4X9YS+pDvywttTeSS3F110fK8FvjFo5Z5bWsnUF9Ng6Xk7Sa4FEdDQauWcv+Z+1VoP7 +C4JLtF1EjJ/nTirLTYlHz+xq+lGGMVoPGPoXGrqaxSV+Rws20vgnD4mf1/Hhsqld2Nt 8kXx9gJYYVRPTh+G1eKTn2b4Afl/5OjsUG8aL41XFGB4NuzCEQbXdA70BcP0fThSh9gG 6Gdw==
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=esPCyvAWzksjGTIju7EOsBaVxbzbGZwISB0s6mm212w=; b=IIu53JJ6CgyqN/1NTHzIh9PaxhUSsTusle3aXLGSc/805OaYabYUvy0ZGQ+1a7YLaj y++WjV9/poIfjVOfmbWzLgWxC9tFUCVg7PW0JJyRNosNTp6Ldpv1ukJ+DDt1aqr+RSDp Ph2LMkXYbZ7jEkaZ94eXko87oVSbAOmQVrBUk+LZ9ZlOYNsAFVA4vynyoJyQicu1Rrw3 NexZLmoQknIA4y7VZ3/yxywbzKSIRP5qr44SJJ2Jj/GtXvCvP2/jlrqruQdL42KAg43z AoDhE5dYSm0xgvcPy0VfnR0X92zvxKi+lHpxtIvtCH9ygAIwk3n9W7bWbUbyo3ogp74j F2iw==
X-Gm-Message-State: ALoCoQnSMP970xbXT0UReAD90likFllmxrj4MMczD8rghfLW/HSrd81aqeQEpiUntHu1sr+n22Hzh0K64GTf0r9RStDOX3OprhVlE4iTQXOmIcHls8QZ2DUv2+WDcHemgz8Zi1GLoUTe7InVQ/BSxF7h9aJWsUPsXWoJQxtARoJDrZ5BRUiQUo5IM4/VBy4QaF5ZqOauvvrJ
MIME-Version: 1.0
X-Received: by 10.52.121.113 with SMTP id lj17mr9022314vdb.21.1391783846523; Fri, 07 Feb 2014 06:37:26 -0800 (PST)
Received: by 10.52.230.105 with HTTP; Fri, 7 Feb 2014 06:37:26 -0800 (PST)
In-Reply-To: <52F4568B.3010201@stpeter.im>
References: <CABrd9SQ7EV5hZ-cEP3DLsBTN5WAwxUFpxndX=iUXzhJ68fu-6A@mail.gmail.com> <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> <CABrd9SQr+-XTKDAw5O65doHYiQHw+FSGXLDnED2AZ7dzWzwxLw@mail.gmail.com> <52F3DADF.3030708@stpeter.im> <52F4568B.3010201@stpeter.im>
Date: Fri, 7 Feb 2014 14:37:26 +0000
Message-ID: <CABrd9STD1nfs6y4miSMq6mVPE4g92mEfKVYhU1xpmYCE5n6QCw@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: Fri, 07 Feb 2014 14:37:31 -0000

On 7 February 2014 03:44, Peter Saint-Andre <stpeter@stpeter.im>; 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 <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?
>>
>> 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" (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.

Sounds good to me.

>
> Peter
>