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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Sep 2015 22:25:01 -0500

Hi,

This is my AD evaluation of draft-ietf-stox-7248bis-05

Summary:

This is not quite ready for IETF last call. There are a number of SIP 
errors in the examples, and I think we need some more text to discuss a 
potential privacy issue. There's some questionable use of 2119 keywords, 
and a few other comments.  Details follow.

Thanks!

Ben.

-- 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 
[email-masked] and [email-masked] both subscribe to 
sip:[email-masked], what if Carol wants to tell Alice that she is 
available, but Bob that she is not? (This is allowed in SIP.) 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. 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.

-- 2119 Keywords.

There's quite a number of 2119 keywords used to describe existing 
normative SIP and XMPP behavior. Those should be written in descriptive 
language, or very clearly attribute the authoritative source. (There are 
a few attributed keywords, but many are not.)

-- section 4, 1st bullet:

"Instead of forwarding a SUBSCRIBE message to the SIP user, the Presence 
Server and SIP User Agent would interact via the ’presence.winfo’ 
event package"

This is only true if the presentity has not already setup policy to 
allow the subscriber to subscribe. Typically, this happens on the 
initial subscription, and future subscriptions may not require the 
presence.winfo interaction.

"The SIP User Agent would then authorize the subscription through..,"

Typically, the user agent persistently authorizes the _subscriber_. 
(Remembering that in SIP the subscription is ephemeral. )

-- Example 2:
The "To" tag should not exist on the first request in a dialog. The tag 
value is learned from the SIP Response (200 OK in this example). The UAC 
does not know the tag value at the time of the initial SUBSCRIBE 
request. (Note that this repeats in later examples)

-- Example 3:
The From and To values are swapped. Remember that a SIP _response_ uses 
the exact same From and To as in the request. (Except for adding the To 
tag in a response to a request that did not contain one.) (Note that 
this repeats in later examples.)

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

-- 5.2.3

The flow and message details are missing the final SIP NOTIFY request.

-- Example 8:

The request-URI should match the peers Contact field value.

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

- I don't think it's correct to try to map CSeq. That's an artifact of 
the SIP state machine that seems
meaningless to the XMPP side. (Same for table 2)

-- 6.2, note 5:

The NOTIFY with a subscription state of "terminated" tears down the SIP 
subscription. Is that the intent? Why would the unavailability of the 
contact end the SIP subscription?

-- note 7:

Do you expect a SIP Presence UA to do something useful with the <show/> 
element ? Most will probably ignore it.

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

"... whenever an XMPP-to-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" ..."

I would have liked to see that discussed in the relevant procedures 
section(s).

-- Editorial Comments and nits:

-- 5.2.2, 2nd paragraph:

Technically, RFC 6665 doesn’t talk about “presence” subscriptions,
  but it does give the rules for SIP-events subscriptions in general. 
Should the citation be to 3856?

-- 5.3.1:
The flow leaves out the SIP responses. That's okay if it's on purpose, 
but it would be good to mention you are doing so. (especially since the 
previous examples showed them.)

- 2nd paragraph after example 10: "Request-URI or To header"
Shouldn't this just be the Request-URI?

-2nd paragraph after example 11:
This also needs a NOTIFY. You mention one in the following paragraph for 
the declined case, but you need one in either case.

-- 5.3.2, 1st bullet:
"will seem strange to the XMPPcontact"

Does the contact's human typically get notified of this?

- 2nd bullet:
This description is confusing. You aren’t maintaining the SIP 
subscription, just the xmpp subscription.

-- 2nd bullet, sub-item 2:

Do I understand this to mean the XMPP gateway infers availability of the 
SIP user from the SIP user’s subscription? That should come from a 
reciprocal subscription. Just because a SIP user subscribes to someone 
else's presence doesn't mean that user is available. Just because he 
doesn't doesn't mean he is not.

Also, how does this violate the SIP semantic?

-- 6.2:
7 and 8 seem mostly redundant—and there doesn’t seem to be a 
citation for 8 in the table.

-- 7:

This is about polling, right? It seems like polling and subscribing are 
just two ways to request presence info.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 23 Sep 2015 20:52:39 -0600

Hi Ben, thanks for the continued careful reviews. Comments inline.

On 9/21/15 9:25 PM, Ben Campbell wrote:
> 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
> that server distributes it among her subscribers.

Yes, this is the usual broadcast model for presence in XMPP.

> I _think_ this can

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.

> a few attributed keywords, but many are not.)

Agreed. I'll check those over and scrub the text.

> Server and SIP User Agent would interact via the ’presence.winfo’ event
> package"
>

Right. How about:

OLD
       Instead of forwarding a SUBSCRIBE message
       to the SIP user, the Presence Server and SIP User Agent would
       interact via the 'presence.winfo' event package, to which the SIP
       user would be subcribed.

NEW
       Instead of forwarding a SUBSCRIBE message
       to the SIP user, the Presence Server would act on the basis of a
       policy set by the SIP User Agent using the 'presence.winfo' event
       package, to which the SIP user would be subcribed.

> (Remembering that in SIP the subscription is ephemeral. )

It's hard to remember unless I put on my SIP glasses. ;-)

> request. (Note that this repeats in later examples)

Correct.

Does this also apply to the NOTIFY messages later in the spec?

> this repeats in later examples.)

Will fix.

> values are useful examples. (Repeats in later examples)

Noted.

> The flow and message details are missing the final SIP NOTIFY request.

The use case here is that the XMPP user no longer wants to receive 
presence information about the SIP user. Is the SIP NOTIFY tiggered 
because there's an assumption that the subscription needs to be 
bidirectional?

> The request-URI should match the peers Contact field value.

Ack.

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

> meaningless to the XMPP side. (Same for table 2)

OK.

> contact end the SIP subscription?

Hmm. I would have thought this falls out from the ephemeral nature of 
subscriptions in SIP. What you write would suggest that it's OK for the 
SIP user's subscription to last beyond the XMPP user's presence session 
(for example because the XMPP user might start another presence session 
during the life of the SIP user's subscription). I suppose that would be 
fine.

> element ? Most will probably ignore it.

Losing that information along the way would guarantee that a presence UA 
can't do something useful with it; preserving the information seems helpful.

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

> long-lived subscription to a SIP user’s presence, it MUST first send an
> XMPP <presence/> stanza of type "probe" ..."
>

OK, I'll see if we can include it earlier in the document.

> Should the citation be to 3856?

Actually I think this paragraph should cite both:

    In accordance with Section 6.7 of [RFC3856], the XMPP-to-SIP gateway
    MUST consider the subscription state to be "neutral" until it
    receives a NOTIFY message with a Subscription-State header [RFC6665]
    whose value is "active".

> previous examples showed them.)

I'm happy to add them.

> Shouldn't this just be the Request-URI?

Given that the SUBSCRIBE can't have a To header yet (see above), yes.

> the declined case, but you need one in either case.

Yes. The XMPP server will generate a presence notification in this case, 
so that's the primary NOTIFY of interest here, I think.

> Does the contact's human typically get notified of this?

Only the first time. It would be strange in XMPP to continually receive 
unsubscribe events whenever an ephemeral SIP subscription happens to 
expire (and subscribe events whenever a subscription is renewed).

> subscription, just the xmpp subscription.

"Treat the subscription as if it were long-lived" might be clearer.

> doesn't doesn't mean he is not.

This flow describes what happens when the SIP user ends its presence 
session. In that case, it seems to me that sending a presence stanza of 
type "unavailable" to the XMPP user is appropriate (when the gateway 
treats the subscription as if it were long-lived).

> Also, how does this violate the SIP semantic?

There's a mismatch in the meaning of subscribe. Treating a SIP 
subscription as if it were long-lived means the gateway follows the XMPP 
subscription model, not the SIP subscription model. A gateway 
implementer needs to choose which model to honor, and if it chooses the 
XMPP model then it's not honoring the SIP model (and vice-versa).

> -- 6.2:
> 7 and 8 seem mostly redundant—and there doesn’t seem to be a citation
> for 8 in the table.

That seems to be a copy-paste error.

> just two ways to request presence info.

Yes, the good way and the bad way. :-)

Perhaps it's not sensible to talk about polling for presence, but I 
think we included this for the sake of completeness.

Peter

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

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Sep 2015 13:55:51 -0400

Thanks for the quick response. More inline; I've removed sections that 
do not seem to need further discussion.

Ben.

> On 9/21/15 9:25 PM, Ben Campbell wrote:

[...]

>> event

That works for me.

> Does this also apply to the NOTIFY messages later in the spec?

The NOTIFY requests will always be part of an existing dialog, so those 
should have both from and to tags.

[...]

> because there's an assumption that the subscription needs to be 

No, there is no assumption that subscriptions are bi-directional. But a 
NOTIFY request is needed to send the SIP subscription dialog. The 
SUBSCRIBE with expires=0 merely triggers that notify.

 From RFC 6665, section 4.4.1:

       A subscriber may send a SUBSCRIBE request with an "Expires" 
header
       field of 0 in order to trigger the sending of such a NOTIFY
       request; however, for the purposes of subscription and dialog
       lifetime, the subscription is not considered terminated until the
       NOTIFY transaction with a "Subscription-State" of "terminated"
       completes.

[...]

> That could get messy. I'll need to think about it and propose text.

I agree on the messy. It's worth some discussion about whether it makes 
sense to model multiple tuples as if they represented multiple 
resources. My kneejerk response is that is the easiest approach, even if 
it might not always be strictly true. (In my mind, modeling resources as 
tuples seems to make more sense when going from xmpp to sip.)

>> meaningless to the XMPP side. (Same for table 2)

I meant to go on and say that if a gateway decided to map id to CSeq to 
save local session state (with some scheme that preserved the semantics 
for either side), that would be perfectly acceptable--but there's no 
need to standardize it.

> subscriptions in SIP. What you write would suggest that it's OK for 
> the SIP user's subscription to last beyond the XMPP user's presence 
> session (for example because the XMPP user might start another 
> presence session during the life of the SIP user's subscription). I 
> suppose that would be fine.

I think of the SIP dialog as representing the subscriber's active 
interest. The subscriber does not necessarily stop caring just because 
the contact became unavailable--as you say, he might come back.

> Losing that information along the way would guarantee that a presence 
> UA can't do something useful with it; preserving the information seems 
> helpful.

Okay. It might be worth a note that the sender should not depend on the 
receiver to render it.

> relays that are shared across XMPP domains from different trust 

Okay

[...]

> receives a NOTIFY message with a Subscription-State header [RFC6665]

WFM

>> previous examples showed them.)

That would solve my concern. A note that they are omitted on purpose 
would also solve my concern.

> Given that the SUBSCRIBE can't have a To header yet (see above), yes.

Hmm, it has a To header--just not a To header _tag_. (I don't think that 
effects this answer, but I hope we don't have a misunderstanding in the 
previous sections.)

> Yes. The XMPP server will generate a presence notification in this 
> case, so that's the primary NOTIFY of interest here, I think.

I think it's still worth mentioning that it happens. And that brings up 
another question: A RFC 6665 notifier is required to send an "immediate" 
NOTIFY. Do you think the presence stanza will reliably arrive at the 
gateway in time to be considered "immediate"? If there's any likelihood 
of delay, the gateway may need to send a "pending" NOTIFY.

[...]

> "Treat the subscription as if it were long-lived" might be clearer.

WFM.

> session. In that case, it seems to me that sending a presence stanza 
> of type "unavailable" to the XMPP user is appropriate (when the 
> gateway treats the subscription as if it were long-lived).

While it's probably not common in practice, it's perfectly okay 
according to the protocol for a SIP user to stop subscribing to a 
resource, while continuing to send updates to that resource on a 
reciprocal subscription. It might be reasonable to assume the user to be 
unavailable if you have no information to the contrary, but this advice 
seems to suggest overriding presence information sent explicitly by the 
SIP user with presence information inferred from the subscription.

> subscription as if it were long-lived means the gateway follows the 
> XMPP subscription model, not the SIP subscription model. A gateway 
> implementer needs to choose which model to honor, and if it chooses 
> the XMPP model then it's not honoring the SIP model (and vice-versa).

I think this depends on the resolution to the previous comment, but I 
would say that if the protoocl behavior expectations of the SIP 
subscriber are met, the semantic has not been violated.

[...]

> think we included this for the sake of completeness.

I guess my objection was to characterize "polling" as a "request" for 
presence information, as if subscribing was not also a way of 
"requesting" that. I don't object to mapping between probes and 
zero-duration subscriptions.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 28 Sep 2015 20:15:43 -0600

Proposed text inline.

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

>> values are useful examples. (Repeats in later examples)

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

> That could get messy. I'll need to think about it and propose text.

I still need to think about that issue.

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 28 Sep 2015 20:39:17 -0600

> do not seem to need further discussion.

Likewise.

[...]

>        A subscriber may send a SUBSCRIBE request with an "Expires" header

Thanks for the clarification.

> it might not always be strictly true.

That's how I've been thinking about the matter, but I need to ponder it 
further.

> (In my mind, modeling resources as

I think your initial intuition was correct. In XMPP the 'id' attribute 
is not a sequence number, whereas in SIP the CSeq header values are, in 
request dialogs, strictly monotonically increasing. Thus I don't think 
the semantics align well enough to even suggest a mapping.

Correct.

> Okay. It might be worth a note that the sender should not depend on the

Actually the XMPP sender (or the sender's client) doesn't necessarily 
know that the receiver is a SIP user. Therefore I'm not sure what we can 
say about the sender. At most perhaps we can add a sentence like this:

        However, there is no guarantee that the SIP receiver will render
        a standard XMPP <show/> value or custom extension.

>> relays that are shared across XMPP domains from different trust realms.

See the other message I just sent in this thread.

> effects this answer, but I hope we don't have a misunderstanding in the

Right, no tag. We're on the same page.

> of delay, the gateway may need to send a "pending" NOTIFY.

Not sure. I'll think about that some more.

> SIP user with presence information inferred from the subscription.

Yes, such a difference is possible in XMPP, too, depending on the 
subscription state.

Let me see if I can formulate some text to address this scenario, and 
clean up the current text referenced above.

> subscriber are met, the semantic has not been violated.

Maybe. :-)

It still seems to me that the gateway is enforcing one model or the 
other. Perhaps "violate" is a strong word in this context, though.

> zero-duration subscriptions.

Ah, I see. I suppose we meant "one-time request" as opposed to the 
"standing request" that is a subscription.

Peter

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 22:16:52 -0500

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

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

Works for me, thanks.

> 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:[email-masked];gr=hdg7777ad7aflzig8sf7>

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

WFM

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 22:32:31 -0500

[...]
> know that the receiver is a SIP user. Therefore I'm not sure what we 
> can say about the sender. At most perhaps we can add a sentence like 
> this:

Of course, by "sender", I meant "gateway" :-)

WFM.

[...]
> Not sure. I'll think about that some more.

It might be reasonable to punt this to the implementation to decide, 
with some guidance about what to do if you can't immediately send a 
"real" NOTIFY. And on reflection, this gets tangled up with 
authorization--the "pending" NOTIFY is more to say the authorization has 
not yet been determined. If the subscriber is known to be authorized, 
then rather than a "pending" NOTIFY it might just send a normal NOTIFY 
with some default presence state, then send the real presence when it 
gets it. (The subscriber's user experience might be a to initially see 
the entity as "closed" then quickly transition to "open".)

[...]

> other. Perhaps "violate" is a strong word in this context, though.

I think we may be reading too much into the "ephemeral" subscription 
model, while still trying to think of an xmpp subscription and a SIP 
subscription of modeling the same thing. Both XMPP and SIP have an 
ephemeral component and a long-lived component. In XMPP, the 
subscription is long lived, and the presence session is relatively 
ephemeral. In SIP, the authorization policy, and the presence of an 
entity on a contact list are long lived, and the subscription is 
ephemeral.

So if we think of an XMPP subscription as equivalent to SIP subscriber 
authorization, and an XMPP presence session as equivalent to a SIP 
subscription, I think we can avoid violence to the assumptions of either 
side.

[...]

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 29 Sep 2015 10:32:10 -0600

[...]

> value should be unique per device.

OK I will see how to update the text and examples here. More soon. :-)

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 30 Sep 2015 10:25:19 +0200

Sorry for coming late folks, looks like you got almost everything sorted out :-)

> It might be reasonable to punt this to the implementation to decide, with some guidance about what to do if you can't immediately send a "real" NOTIFY. And on reflection, this gets tangled up with authorization--the "pending" NOTIFY is more to say the authorization has not yet been determined. If the subscriber is known to be authorized, then rather than a "pending" NOTIFY it might just send a normal NOTIFY with some default presence state, then send the real presence when it gets it. (The subscriber's user experience might be a to initially see the entity as "closed" then quickly transition to "open”.

You could still send an empty NOTIFY with subscription state “active”, to indicate that the it has been allowed by the policy, but there is no presence state to show at this moment. How to interpret that is of course implementation specific.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 09:16:17 -0500

On 30 Sep 2015, at 3:25, Saúl Ibarra Corretgé wrote:

> authorization--the "pending" NOTIFY is more to say the authorization 
> has not yet been determined. If the subscriber is known to be 
> authorized, then rather than a "pending" NOTIFY it might just send a 
> normal NOTIFY with some default presence state, then send the real 
> presence when it gets it. (The subscriber's user experience might be a 
> to initially see the entity as "closed" then quickly transition to 
> "open”.
>
>
> You could still send an empty NOTIFY with subscription state 
> “active”, to indicate that the it has been allowed by the policy, 
> but there is no presence state to show at this moment. How to 
> interpret that is of course implementation specific.

Also true.

Ben.