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

[Peter Saint-Andre - &yet <[e-mail]>]

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
>> [e-mail] and [e-mail] both subscribe to
>> sip:[e-mail], 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":
>
> http://tools.ietf.org/html/rfc6121#section-4.6
>
> 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
    example:

    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
       registration).

    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
       simple.example.com ought to allow only users within the
       example.com domain to access the XMPP-to-SIP gateway, not users
       within example.org, example.net, or any other domain unless they
       are part of a multi-tenant environment as example.com).

Peter

-- 
Peter Saint-Andre
https://andyet.com/