Selecting and Securing a WIM Solution

Chapter 2 tion. With the lines blurring between wireless and wireline Internet access, and with the growth of multiservice providers, there are new opportunities for service providers to use messaging to attract and retain customers and to add new features and benefits that are not possible on today’s stripped- down “fun” messaging services.

2.5.7

The Future of MIM

Future MIM systems will likely include rich and robust presence- and loca- tion-based service capabilities, which will enable users to detect the pres- ence, availability, and/or the location of fellow MIM/WIM users. This will make the WIM systems more robust and pervasive, providing more valu- able functionality. Interoperability between MIM/WIM systems should be possible by leveraging network mediation processes to enable messaging. By providing such fixed IM system features, it is expected that it will lead to a much wider scale of adoption and usage in the future.

2.6

Selecting and Securing a WIM Solution

Most of our book describes how to secure stationary IM and wireless sys- tems as they relate to mobile laptops. Securing mobile systems such as phones and PDAs will have you feeling more at the mercy of the vendor than with the fixed and wireless LAN systems. For that reason, we have chosen to give an overview of what you should expect (and require) a ven- dor to provide, rather than what you should do yourself. As a selection guideline, the following requirements should be considered when selecting a WIM enterprise solution:

It must support multiple clients. Most businesses have not standard- ized on mobile devices and have allowed departments or users to make the decision. Rapid innovation of device selection and falling hardware and connectivity costs have contributed to the diversity of devices within the enterprise. Therefore, enterprises that deploy wireless IM systems must select a solution that supports a multitude of clients. For example, you must consider the support for RIM, Palm OS, J2ME/BREW, Pocket PC, and two-way SMS when select- ing a solution.

The solution should be able to act as a gateway/proxy between user devices and each of the back-end corporate and/or public IM services.This will require features such as multiple “connectors,” which can speak to the

50 2.6 Selecting and Securing a WIM Solution

native protocol of the back-end service. In this regard, the server should be able to connect to all of the back-end services, consolidate profiles and features from all services, and make them available via a single client interface. This type of extensible architecture will allow additional IM services to be supported in the future without the need to upgrade client software.

Any solution should allow users to connect to any combination of enter- prise IM services and public IM services simultaneously.Your solution should be able to support public IM systems such as AOL Instant Messenger, MSN Messenger, Yahoo! Instant Messenger, ICQ, and Jabber.

The proposed solution should not restrict wireless device selection. It should be able to support devices such as RIM, Palm OS, any two- way SMS capable device, BREW, J2ME, and Pocket PC.

Any chosen solution should preserve the familiar desktop IM experience.

Wireless IM must be easy to learn and use, replicating the PC-based experience, in order to be effective.

It should integrate with existing network management tools.Enterprises should not make the mistake of integrating point solutions, and they should not accept solutions requiring multiple systems manage- ment tools. Vendors with wireless IM solutions that integrate with popular network management tools such as Microsoft’s Active Directory for unified communications infrastructure management should be given preference.

It should feature strong authentication, such as 3DES encryption, with two-factor authentication implemented in order to verify user identity.

It should encrypt all data sent over-the-air to wireless devices. It should be able to prevent corporate information from being sent outside the firewall unencrypted. It should also authenticate users by integrating directly with corporate directory services through Active Directory or LDAP.

Any solution should integrate with corporate email.The solution should allow users to send email to offline IM contacts and it should connect to enterprise email systems such as Microsoft Exchange, Lotus Dom- ino, POP3, and IMAP mail servers.

It should provide carrier-grade reliability and scalability. Since Enter- prise Wireless IM serves as a cornerstone of corporate communica- tions infrastructure, the solution must be scalable and reliable. Preferred solutions should be hardware independent, fully cluster-

2.7 Summary 51

Chapter 2 aware, and developed using open standards. The solution should also be capable of accommodating large amounts of traffic without com- promising performance. For example, if the solution is hardware independent, it should allow an organization to choose the hardware size best suited to its specific, unique performance needs. A flexible solution architecture will allow it to be fully clusterable for even greater scalability and fault tolerance. Enterprises should only select wireless IM solutions that can scale linearly with hardware, ranging from hundreds to tens of thousands of users.

Any proposed solution should include flexible enterprise reporting tools.

Corporations require reporting to analyze usage patterns in order to accurately forecast billing, enforce compliance to propriety standards, and manage data for legal purposes. Businesses must select IM soft- ware that offers reporting at both the aggregate and user level, and, at the very least, such solution reporting should include the number of messages sent and received (by user) and preserve and maintain mes- sage content logs. These reports can be used to show usage at the aggregate and individual user levels. Web-based reports should be able to be run at any time and exported in various output formats, such as HTML, XML, .pdf, .doc, and so on.

2.7

Summary

In this chapter, we have discussed the ever-growing prevalence of IM usage, both at home and in the workplace. The widespread usage of IM continues to move it from a public forum to a commonplace tool in enterprise work- places. We distinguished between the presence service and the IM service, introducing specific terminology that is used in the IM world. A high-level overview of how IM worked, from download and installation of a client to subscription and activation, was presented. We compared the basic IM fea- tures across four of the major public IM solution providers, and, finally, we took a look at some of the additional considerations the enterprise IM (EIM) implementers must consider before deciding whether or not to introduce IM into their environment.

Clearly, IM usage is gaining momentum. It is still a decision that a manager should not make lightly, because it introduces other factors into the business, such as policy changes, disposition of records, management of evidentiary materials, training, susceptibility to malware attacks, and so on. A company could be held responsible if its negligent use of IM did harm in some manner to another company or to an individual during the

52 2.8 Endnotes

course of business. This is still a new, evolving area of interest in the legal offices of corporations around the world. Much more needs to be done to standardize practices in this area. In the next chapter, we take a look at the development of protocols and standards that have evolved to support IM as we know it today.

2.8

Endnotes

1. E. Shiu and A. Lenhart. “How Americans Use Internet Messag-

ing.” Washington, DC: Pew Internet & American Life Project, August 31, 2004.

2. FC 2778, “A Model for Presence and Instant Messaging,” Febru-

ary 2000, ed. M. Day et al., IETF NWG, http://www.ietf.org.

3. FC 2779, “Instant Messaging/Presence Protocol Requirements,”

February 2000, ed. M. Day, et al., IETF NWG, http://www.ietf.org.

4. M. Sequineau. “Choosing the Right EIM Solution,” JupiterMe-

dia/CIO update online article, January 3, 2005. Retrieved from http://www.cioupdate.com/trends/article.php/3453731.

53

3

IM Standards and Protocols

As we mentioned earlier, there are a lot of players in the public IM space today. Many of these IM players (and many other players less known than MSN, AOL, ICQ, and Yahoo!) are vying to establish the dominant IM standard in this new arena. All of the players are continually introducing new applications and features to take advantage of all IM has to offer and to stand out from their competitors. It seems fairly obvious that having all these incompatible players is problematic at best. It appears that things will likely converge on some combination of SIP (Session Initiation Protocol) and SIMPLE (SIP for IM and Presence Leveraging Extensions) versus XMPP (Extensible Messaging and Presence Protocol). There is a question as to whether there will be just one standard or if some blend of one or more standards will prevail. Of course, this is assuming the standard comes from the IETF and is not driven by another organization, such as the mobile car- rier forum called Wireless Village, which is not only pushing an architecture that’s very similar to the other two architectures but is also developing and publishing a completely separate set of protocols. If it (or others) adds yet another protocol, the mix of interoperability will become even more inter- esting and challenging.

3.1

Extensible Messaging and Presence Protocol—

RFC 2778

The Extensible Messaging and Presence Protocol (XMPP) is the IETF’s formalization of the core protocols created by the Jabber community in 1999 [1]. A brief chronology of activity related to Jabber and XMPP in the IETF standards process is warranted. In August 1999, Jeremie Miller of the Jabber open-source project submitted a statement pledging the Jabber community’s support for the IETF standards process. This statement was consistent with the founding impetus of the Jabber project: to foster and

54 3.1 Extensible Messaging and Presence Protocol—RFC 2778

support open standards and interoperability in the area of IM and pres- ence. In June 2000, Jeremie and other members of the Jabber project sub- mitted an Internet Draft to the IM and Presence Protocol Working Group (IMPP) documenting the Jabber protocol. Unfortunately, the Jabber com- munity was not well organized in those days, nor was it strongly focused on protocol development. Thus, the initial Internet Draft expired without the Jabber community following up or working closely with the IMPP or any other IETF efforts.

However, in 2001, the Jabber Software Foundation (JSF) was formed to provide some organization among the growing number of open-source projects and commercial entities building or using Jabber technologies. One of the core mandates of the JSF has been to document the XML pro- tocol used by the Jabber community, and to manage the growth of that pro- tocol. This organizational effort has led to the more recent involvement of the Jabber community in the IETF standards process.

In late 2001 and early 2002, prominent members of the Jabber com- munity decided to once again submit the Jabber protocol to the IETF. The first submission was made in February 2002 as an informational Internet Draft. Following on the success of this submission, it was decided to explore the possibility of forming an IETF Working Group devoted to dis- cussion of the Jabber protocol, under the neutral name of XMPP. As a result, three interrelated Internet Drafts were submitted on June 21, 2002. On July 15, 2002, an XMPP “Birds of a Feather” session was held at the 54th IETF meeting in Yokohama, Japan. Given the overall favorable reac- tion to XMPP at that meeting, it was decided to proceed further by submit- ting a proposed working group charter to the Internet Engineering Steering Group (IESG). The IESG is responsible for technical management of IETF activities and the Internet standards process. As part of the Internet Society (ISOC), it administers the process according to the rules and procedures that have been ratified by the ISOC trustees. The IESG is directly responsi- ble for the actions associated with entry into and movement along the Internet “standards track,” including final approval of specifications as Internet standards. On October 31, 2002, the XMPP Working Group was approved. On November 3, 2002, updated Internet Drafts were submitted

for xmpp-core and xmpp-im. The first meeting of the XMPP Working

Group was held at the 55th IETF meeting in Atlanta, Georgia, on Novem- ber 19, 2002, including presentations by Jeremie Miller, Joe Hildebrand, and Peter Saint-Andre.

In early 2003, the two base XMPP drafts went through several revision cycles and were published defining stringprep profiles for node identifiers