Beyond Jabbering: Federated XMPP Jorj Bauer <[email protected] > Tim Callahan <[email protected] > October 2009
Beyond Jabbering: Federated XMPP
Jorj Bauer <[email protected]>Tim Callahan <[email protected]>
October 2009
About This Talk: What
• Presence and Integrated Commuincations working group (PICwg)
• Loose SSL-based Federation
• Shibbolized Federation
• Commercial XMPP Federation Efforts: Google and Microsoft
About This Talk: When
About This Talk: Why
• I2 Presence and Integrated Communications Working Group (PICwg)
• XMPP as a conduit to transit trustable presence information
• XMPP as a common carrier for integration of communications
About This Talk: Why
• I2 Presence and Integrated Communications Working Group (PICwg)
• Phase 1: gain acceptance and deployment of XMPP servers
• Phase 2: advance the state of XMPP
Phase 1: PIC@edu
• Simplify campus IM deployments
• Promote interoperability among Internet2 members’ IM services, including the use of federated identity
• Enable experimental development on a common platform (i.e. XMPP)
• Enable inclusion of advanced communications services and advanced presence
Phase 2: advance XMPP
• Recently focused on federation, but we have some other plans...
About This Talk: Caveat
• I’ll be hand-waving over some details
• Much of what I will say is a close approximation of the reality
• Almost all of this is malleable, and we’d love you to come help us... malleate
Loose SSL Federation
Loose SSL Federation
• Use case: policy-driven encrypted connections (real case, unnamed U.)
• All IM communication must be verifiably end-to-end encrypted, or explicitly blocked
Loose SSL Federation
What, exactly, are we talking about?
• Confederation of institutions that share a similar set of policies (at least enforced SSL, maybe others)
• Federation’s CA issues SSL certificates
• Confederate servers only trust this CA
Loose SSL Federation
Loose SSL Federation
Loose SSL Federation
Loose SSL Federation
Loose SSL Federation
Loose SSL Federation
Why isn’t this easy?
• Servers don’t have the flexibility required to apply different policies to multiple individual servers
• Clients wouldn’t trust a new CA; therefore, servers must use two certs
• No appropriate CA exists today and running a secure CA is non-trivial
Loose SSL Federation
How do we proceed?
• Augment server software to offer different certificates between C/S and S/S connections
• Operate a CA temporarily for testing purposes
• Identify other possibilities (e.g. SSL certificate attributes) for production...
Loose SSL Federation
How do we proceed?
• Expand server capabilities to define server-to-server connectivity requirements on a per-server basis
• Simple “require SSL” options would be a good start
Loose SSL Federation
How do we proceed?
• Or, something new: revisit server “buddy lists” distribute the confederation in a web of trust
• XEP-0267: Server Rosters
Loose SSL Federation
* jabber.stanford.edu: “In”* talk.google.com: “Out”* picdemo.internet2.edu: “In”
* jabber.upenn.edu: “In”* talk.google.com: “Out”
picdemo client wants to talk to someone @jabber.stanford.edu...
picdemo.internet2.edu
jabber.upenn.edu
Loose SSL Federation
upenn server replies “Yes, Stanford’s In”
picdemo server does not find stanford in its list; contacts a known “In” partner to see if it does
picdemo client contacts picdemo server
* jabber.stanford.edu: “In”* talk.google.com: “Out”* picdemo.internet2.edu: “In”
* jabber.upenn.edu: “In”* talk.google.com: “Out”
Loose SSL Federation
picdemo server updates its roster
* jabber.stanford.edu: “In”* talk.google.com: “Out”* picdemo.internet2.edu: “In”
* jabber.upenn.edu: “In”* talk.google.com: “Out”* jabber.stanford.edu: “In”
Loose SSL Federation
picdemo server is able to find policy and contacts stanford.edu with the “In” certificate
Client gets its connection, because
* jabber.upenn.edu: “In”* talk.google.com: “Out”* jabber.stanford.edu: “In”
Loose SSL Federation
• A different tack: client end-to-end encryption awareness, with server accessibility
• XEP-0219: Hop Check
Loose SSL Federation
• If each of these connections is encrypted, the client should be able to display that fact for the user
• Servers should be able to tell that the connection is end-to-end encrypted, and reject inappropriate connections based on policy
Loose SSL Federation
Where are we today?
Shibbolized XMPP
Shibbolized XMPP
• Shibboleth: framework for web-based authentication and SAML assertion passing
Shibbolized XMPP
• Shibboleth: framework for web-based authentication and SAML assertion passing
... so there is some work to be done
Shibbolized XMPP
• Shibbolized Jabber does not necessarily “win” from an AuthN perspective (although it could)
• From an AuthZ perspective, the possibilities are intriguing...
• Allow all student/staff/faculty at member Universities to access a chat room
Shibbolized XMPP
• How do we get SAML data into XMPP servers?
• If we had a command-line SP, then
• modified the XMPP server to retrieve SAML data via Shibboleth, then
• ... ?
Microsoft OCS
Microsoft OCS
• Office Communications Server 2007 R2 XMPP Gateway
• Licensing updated to make this essentially “free”
• http://www.microsoft.com/presspass/features/2009/oct09/10-01ucinterop.mspx
Microsoft OCS
• Federates with AOL (without additional license requirements)
• Federates with Yahoo! (add’l license required, but dropped 50% from last year)
• Now federates with XMPP, too
Microsoft UCOIP
• Unified Communications Open Interoperability Program
• http://technet.microsoft.com/UCOIP
Google Wave
Google Wave
• Launched in May 2009
• Integrates various types of communication
• Uses XMPP for federation behind the scenes
Email Architecture
IM Architecture
Wave Architecture
Wave Terminology
But what is a Wave?
• A collaboratively edited document, consisting of multiple Blips
• The back-end technology that enables one to compose and send Waves
• “Google Wave” is Google’s front-end to their Wave server
Wave Terminology
To draw some analogies...
• A collaboratively edited document, consisting of multiple Blips [email]
• The back-end technology that enables one to compose and send Waves [email server]
• “Google Wave” is Google’s front-end to their Wave server [email client]
Wave Terminology
• Gadget: a plug-in to the web front-end that extends the capabilities of Google Wave
• Robot: a nonhuman participant in a wave which participates via an API
Wave Ideology
Lars Rasmussen, co-creator of Wave, asks the following three questions which summarize his intent...
Wave Ideology
Why do we have to live with divides between different types of communication - email versus chat, or conversations versus documents?
• [Unified communications are important]
Wave Ideology
Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum?
• [Again, unified communications are important - and aim high]
Wave Ideology
What if we tried designing a communications system that took advantage of computers’ current abilities, rather than imitating non-electronic forms?
• [... we would get Google Wave, apparently]
Google Wave: Integration
Demo time: what can we put into a wave?
Google Wave: Integration
Demo time: what can we put into a wave?
Looks like email or IM...
Google Wave: Extension
Wave offers two kinds of core add-ons
• Robots are external nonhuman participants in a conversation, and can do things like fix your spelling
• Gadgets are client-side extensions that can change the way the tool works, like tracking and broadcasting advanced presence info (existing Google-gadgets may work, albeit not multi-user)
Google Wave: Extension
With Robots and Gadgets, we can extend the list of communications types Wave can emulate
voice wikis blogs Twitterbulletin boards...
Where Are Waves?
Wave Information
• http://waveprotocol.org
• http://wave.google.com
• http://code.google.com/apis/wave/
PIC working group
PIC working group
• Have been advocating for local XMPP on campuses
• Believe XMPP is an excellent carrier for future presence and integrated communications projects
• Google Wave is a newcomer to keep an eye on
PIC working group
• PICwg OpenFire cookbook
• Today, Prosody may be easier to deploy
• Not concerned about what product you choose (smacks of sendmail/qmail/postfix)
PIC working group
• Looking ahead: are starting to define new standards that help transit presence information, such as
• Server-to-server rosters
• Secure-only delivery flags
• Presence information transited through components (specifically Wave)
PIC working group
• ... But what we need are folks interested in participating, both in conversation and coding
PIC working group
• Bi-weekly calls: every other Thursday from 4-5 PM (Eastern time)
• Mailing list ([email protected])
• http://pic.internet2.edu/participate.html
Questions?
This slide deck is available as a PDF from
http://www.jorj.org/isc/xmpp09.pdf
• For more about the PICwg, join or browse our mailing list:
http://pic.internet2.edu/participate.html