Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

Peter Saint-Andre - &yet <> Tue, 29 September 2015 02:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 094101B2D57 for <>; Mon, 28 Sep 2015 19:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LWnjD2qBD3S6 for <>; Mon, 28 Sep 2015 19:15:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1D501B2D58 for <>; Mon, 28 Sep 2015 19:15:47 -0700 (PDT)
Received: by ioii196 with SMTP id i196so197052558ioi.3 for <>; Mon, 28 Sep 2015 19:15:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=oJjw/n1vmJRQOl6cIsfmHXRI92bDmgLj/BSZzLwDsCc=; b=d6F+nrBMjltuKKRocw5Kss5SOmjEVXfx7E6b9ii6qi8N4AiI/ZmrgE2Erk2y/hXvqj ruEGJXfNc/fW5Qd9n7RN+w234oiHOG5Y26PMjgurIXTQ9AIUqR6GqLd/14/S+11enNh9 1hEkBco828VXPvLQYWuwTQ0x5YNE4d2/VZV5Q7AZ27zq14ds1cdLlauu8vnnjnHkBbDL w3D5hGQqGJ/ABREQZaUcRm4h6N8MBrp09UpVgvxy97WmLbAMtmflELp1SaMC5jSkOJcV 4NYAzDmT2L7KtulWTAuOZmi0bf0Ds7cfdD+seaBhP98AgvhllRsWHasqCMGU5WuK+fLu 3DPQ==
X-Gm-Message-State: ALoCoQlulD7x0RvMlOPXWjiNIdwLeTmthhU743Dgo1gb6+aGk8kVcXdFSIgxieuT2gWxkRWj9Hrk
X-Received: by with SMTP id 42mr26979054iop.137.1443492946831; Mon, 28 Sep 2015 19:15:46 -0700 (PDT)
Received: from aither.local ( []) by with ESMTPSA id u99sm10030786ioi.0.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 19:15:45 -0700 (PDT)
To: Ben Campbell <>,,
References: <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Mon, 28 Sep 2015 20:15:43 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 02:15:50 -0000

Proposed text inline.

On 9/23/15 8:52 PM, Peter Saint-Andre - &yet wrote:
> On 9/21/15 9:25 PM, Ben Campbell wrote:
>> -- Privacy:
>> I'm concerned that a naive implementation of the gateway could allow an
>> XMPP user to see presence information for a SIP user that they were not
>> authorized to see. The issue is that SIP allows a presentity to send
>> different presence information to different subscribers. For example, if
>> and both subscribe to
>>, what if Carol wants to tell Alice that she is
>> available, but Bob that she is not? (This is allowed in SIP.)
> This also exists in XMPP, where it is called "directed presence":
> However, in XMPP this is the exception, not the rule.
>> Can we be
>> sure the gateway won't take presence intended for Alice and also send it
>> to Bob?
>> I think this is an issue, since if I understand things correctly, an
>> XMPP presentity typically sends one presence stanza to her server, and
>> that server distributes it among her subscribers.
> Yes, this is the usual broadcast model for presence in XMPP.
>> I _think_ this can
>> work as long as we make sure the gateway sends each presence stanza
>> directly to the subscriber that was targeted by the SIP Notify, and
>> never mixes them up. But I think we need some text to describe the issue
>> and give guidance on how to do the Right Thing.
> It can't hurt.
> We actually need a bit of text in the XMPP-to-SIP direction, too. The
> behavior of the XMPP server is specified in RFC 6121, but perhaps it
> would help to mention here that the server adds a 'to' address on each
> presence stanza it generates when it broadcasts the undirected presence
> stanza to the XMPP user's subscribers. This 'to' address is used for
> routing and needs to be honored by the XMPP-to-SIP gateway. From the
> perspective of the gateway, all it knows is that it has a presence
> stanza that it needs to transform into a SIP NOTIFY, and that stanza
> includes a 'to' address - it can't just assume that it can send that
> stanza to any random SIP user (and in fact it doesn't have the
> information it would need to make such decisions, since it isn't privy
> to the XMPP user's roster, which includes the subscription states).
> I'll work to formulate some proposed text and post it in this thread.

I think we can include a paragraph such as the following in the Security 
Considerations and use it to cover the behavior in both directions:

    Presence notifications can contain sensitive information (e.g., about
    network availability).  In addition, it is possible in both SIP and
    XMPP for an entity to send different presence notifications to
    different subscribers.  Therefore, a gateway MUST honor data about
    the intended recipient of a presence notification and it MUST NOT
    route or deliver a presence notification to any other entities.

>> -- Example 4:
>> The Request-URI should match the Contact header field value from the
>> SUBSCRIBE. (Technically, from the last message from the peer, but
>> assuming you don't have them change contacts mid-stream, it's the same.)
>> You also might want to consider whether the aforementioned contact
>> values are useful examples. (Repeats in later examples)
> Noted.

Is your suggestion that we not include the Contact headers, or only that 
we look carefully at the values of those headers?

>> -- Table 1:
>> - I think this could use some more text around what happens if you have
>> multiple XMPP resources, or a SIP presentity sends multiple tuples. The
>> note discusses how to map the resource identifier to the tuple id, but
>> not much about what it means to have multiple of either.
> That could get messy. I'll need to think about it and propose text.

I still need to think about that issue.

>> -- 9, 2nd paragraph:
>> "an XMPP-to-SIP gateway ought to be associated only with a single domain
>> or trust realm"
>> Is this intended to discourage multi-tenant gateways? Does the existence
>> of draft-ietf-xmpp-dna change that?
> No, because that's the same trust realm (i.e., a service under the
> control of a single administrative entity even if that entity hosts
> multiple tenants).
> This text is intended to discourage the gateway equivalent of open
> relays that are shared across XMPP domains from different trust realms.

I suggest that we break up the long sentence there into bullet points, 
and add a few more words...

    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 (because each long-lived XMPP presence subscription
    would typically result in multiple subscription refresh requests on
    the SIP side of an XMPP-to-SIP gateway).  Therefore, access to an
    XMPP-to-SIP gateway SHOULD be restricted in various ways; for

    o  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 an XMPP-to-SIP
       gateway (e.g., not a service that offers open account

    o  An XMPP-to-SIP gateway ought to be associated only with a single
       domain or trust realm (e.g., an XMPP-to-SIP gateway hosted at ought to allow only users within the domain to access the XMPP-to-SIP gateway, not users
       within,, or any other domain unless they
       are part of a multi-tenant environment as


Peter Saint-Andre