Beyond Jabbering: Federated XMPPBeyond Jabbering: Federated XMPP Jorj Bauer Tim Callahan October 2009

Beyond Jabbering: Federated XMPP

Jorj Bauer <[email protected]>Tim Callahan <[email protected]>

October 2009

mailto:[email protected]




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


• Use case: policy-driven encrypted connections (real case, unnamed U.)

• All IM communication must be verifiably end-to-end encrypted, or explicitly blocked


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







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


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


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


How do we proceed?

• Or, something new: revisit server “buddy lists” distribute the confederation in a web of trust

• XEP-0267: Server Rosters


* 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


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.upenn.edu: “In”* talk.google.com: “Out”


picdemo server updates its roster


* jabber.upenn.edu: “In”* talk.google.com: “Out”* jabber.stanford.edu: “In”


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”


• A different tack: client end-to-end encryption awareness, with server accessibility

• XEP-0219: Hop Check


• 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


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/

http://waveprotocol.org

http://waveprotocol.org

http://wave.google.com

http://wave.google.com

http://code.google.com/apis/wave/

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



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:






Documents

Beyond Jabbering: Federated XMPPBeyond Jabbering: Federated XMPP Jorj Bauer Tim Callahan October 2009