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

["Ben Campbell" <[e-mail]>]

On 28 Sep 2015, at 21:15, Peter Saint-Andre - &yet wrote:

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

Works for me, thanks.

>
>
>>> -- 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?

The second. The contact identifies (and routes to) the device that sent 
the containing message. And with RFC 6665, the contact sent by the 
notifier MUST contain a GRUU (RFC 5627).

For example:

       Contact: <sip:[e-mail];gr=hdg7777ad7aflzig8sf7>


It wouldn't hurt for the subscriber to also contain one, albeit the gruu 
value should be unique per device.



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

WFM


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