Subject: Re: [xmppwg] Re: [Simple] "last call" on SIMPLE-XMPP interworking I-D

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Aug 2006 21:22:03 -0600

My apologies for taking so long to incorporate our consensus. Comments
at the end.

Dave Cridland wrote:
> On Wed Jul 19 20:48:25 2006, Adam Roach wrote:
>> Dave Cridland wrote:
>>> A traditional "Jabber transport" would allow gatewaying through it
>>> from any Jid. If instead the XMPP/SIMPLE transport only allows
>>> gatewaying through it from its local XMPP domain, then in order to
>>> mount the attack, the attacker has to obtain several thousand
>>> accounts on that server.
>>
>> As far as I can tell, this solves the problem; however, I think it
>> breaks the solution for most deployments as well. I foresee these
>> gateways being deployed primarily by enterprises who are using one
>> system (SIMPLE or XMPP) so that their users can communicate with
>> enterprises using the other. Limiting interworking to local users
>> makes such use impossible.
>>
>>
> Ah... I'm just limiting XMPP usage to local XMPP users. Any SIMPLE user
> can use the gateway.
> 
> So for enterprises using XMPP "natively", they would need to run an
> XMPP/SIMPLE gateway (or be on the known good list of another, to borrow
> your suggestion below, but I think in practise they'll want their own).
> 
> SIMPLE enterprises don't have to run a gateway, although they may wish
> to if they want to ensure they have access to one.
> 
> 
>>> Of course, you could combine both Adam's proposal and this - only
>>> remote clients get the spurious <iq> hacks.
>>
>> This sounds like a reasonable balance. I think you could extend it
>> further and assert that the <iq/> exchanges are required *except* for
>> servers on a "known good" list provisioned by the gateway administrator.
> 
> Yes, true.

I have just submitted draft-saintandre-xmpp-simple-08 to the Secretariat
containing the following paragraph in the Security Considerations:

******

   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.  To help prevent such an attack, access to an XMPP-
   SIMPLE 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 should 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-SIMPLE
   gateway from users who are not associated with a domain that is so
   related to the hostname of the gateway, it MAY (based on local
   service provisioning) refuse to service such users or refuse to
   communicate with the gateway.  Furthermore, whenever an XMPP-SIMPLE
   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"
   ([email-masked]) of the XMPP user, to which the user's XMPP server
   MUST respond in accordance with [XMPP-IM]; however, the administrator
   of an XMPP-SIMPLE gateway MAY (based on local service provisioning)
   exempt "known good" XMPP servers from this check (e.g., the XMPP
   server associated with the XMPP-SIMPLE gateway as described above).

******

I'll post a note to the list when this I-D has been published, since it
contains several other modifications that address feedback received on
and off the lists.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple