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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Sep 2006 15:34:46 -0600

Any further input on draft-saintandre-xmpp-simple-08?

http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-08.txt

If not, I'll pursue requesting a standards action regarding this I-D.

Thanks!

Peter

Peter Saint-Andre wrote:
> 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
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple