CORPORATE VIEW

There's a wh ole lot of snake oil out there these days. Many vendors will be coming into your office with a hard or soft sell for intranet technologies that will shortchange your corporate future. You heard me--your corporate future, which translated means your job.

There is no need for intranets, only internets. You need to share information with your business partners. The strange thing is, those systems that you spent so long developing for your users in quality control are exactly what you need for your component suppliers. The system you developed for marketing is just what you need for your outside public relations and research firms. If you develop ed these systems for an intranet, you'll have some reworking to do to open up the system enough for new users.

This is not a semantics game. There is a profound philosophical difference expressed by the terms "intranet" and "internet." An intranet means it's all yours, you control every part of it that matters and your trust model is fairly straightforward. When you design an intranet, you might not put any restricted access into your Web-based applications and you may just use a simple clear-text login for the highly restricted information.

An internet is a collection of cooperating networks. The owners put forth the effort to ensure that data moves among various networks so that everyone benefits. Your network and your business partners' networks can work together as an internet. When there are multiple networks, there is, perforce, little trust.

From something as simple as e-mail, to something as complex as client/server, you have to be cognizant of your eventual user base. Are you aware of properly identifying mail users? Does the e-mail package on your user's desk properly show all of the principle Simple Mail Transfer Protocol (SMTP) mail headers as the originator sent them? And can you support an open digital signature and encryption standard such as Secure/Multipurpose Internet Mail Extensions (S/MIME) or Message Security Protocol (MSP) if you have to deal with the Department of Defense? How will you be able to grant your business partners access to key design information without replicating all the data on a business partner system over by your firewall?

Take the High Road It's easy to claim that security is just too hard and that base assumptions on intranet security are valid. The error of this approach is senior management's view of the company as a web of interlocking business partnerships, sometimes with divisions of companies that are in direct competition with your main product line. Special network connections or two machines on a desk are not viable alternatives. To keep your job out of the line of fire (literally), build for an internet today. Your mantra must be that your network is a part of an internet. There is no such thing as an intranet. Repeat this on a daily basis as you choose strategic approaches to your networking needs and tactical solutions.

You can segment your user community as you've always done, but now wi th more classifications. Besides the traditional department/division/corporate access rules, you also need a few external classes. One working set is: owned subsidiary/independent partner/competing subsidiary/public/the competition. This way, you can set up some basic rules of engagement.

Your first rule is to limit everything that's not for the general public. You can do this with simple logins initially. For Web usage, Secure Socket Layer (SSL) certificates might be a good interim improvement on user authentication, but the jury's still out on whether SSL 3.0 will suit the extended enterprise needs. NOS-related approaches really are problematic; your drive letter standard could well be in direct conflict with those of your business partners.

The most interesting model for user authentication on the horizon is the result of the efforts of the Internet Engineering Task Force's IP Security work group, called Oakley /ISAKMP (ftp://ds.internet.net/internet- drafts /draft-ietf- ipsec- isakmp- oakley-00.t xt). This key exchange protocol has all the features deemed necessary by the security community to handle a multipolicy environment typified by an internet consisting of yours and your business partners' networks. Oakley/ISAKMP will start appearing in S/WAN products by year's end and if CommerceNet--which is putting in a major effort to be used for business- to- business applications by vertical industries--can convince Netscape Communications and Microsoft, Oakley/ISAKMP could also be used in SSL 3.0 .

All in All, It's a Long Road Building an internet is a lot more challenging and rewarding than building an intranet. Internets solve more of the real business needs of your company, but it won't be easy. There will be many shortchanged product offerings. These products are not without merit; products such as Microsoft's Point-to-Point Tunneling Protocol (PPTP) offer remote secure access, but are not well-suited for the needs of flexible remote secure access to the networks of multiple business p artners. Less flexible approaches such as SSL and PPTP have tactical value, but we must not lose sight of our real goal: interbusiness applications.

If you concentrate only on building your intranet today, before you know it you may have significant reworking to do to meet your company's competitive goals. Carefully study the trade-offs between fast deployment and reworking or the innumerable upgrades needed to achieve the openness that's truly required, even today. Just remember for whom the bell tolls.

Robert Moskowitz is a software systems specialist at Chrysler Corp. in Detroit, Mich., and a member of the Internet Architecture Board (IAB). He can be reached at rgm@htt-consult-com.