USENIX Symposium on Internet Technologies and Systems (USITS)
by Alain Mayer

The first USITS was held in Monterey, CA from December 8-11, 1997. It was the brainchild of Carl Staelin (HP Labs) and Fred Douglis (AT&T Labs). It was attended by about 200 people from academia, industrial research laboratories, ISP, and Internet companies. Given the success of this first meeting, USITS is likely to become a regular event, probably every 18 months, or so.

The keynote was given by Heide Heiden, senior Vice-President of UUNET Technologies. He started with a brief history of the Internet, from the prehistoric five nodes forming the early ARPANET to the World Wide Web of today. He then focused on the bandwidth problem of today. The capacity of UUNET's backbones will increase by a factor of 1000 for the period of 1996 - 2000. This unparalleled growth makes it impossible to plan ahead more than a year. For example, UUNET does not know for sure how exactly their main hubs will look like in 18 months from now! Their chief scientist, O'Dell, said "if you are not scared by this, you do not understand what is going on"!

The refeered paper session spanned a wide range of interesting topics, such a Web caching, server architectures, and searching. We will focus in this note on the session on security.

The paper by Gong, Mueller, Prafullchandra, and Schemers (all of JavaSoft) introduced the security architecture of JDK (Java Development Kit) 1.2, which will be released in early 1998. JDK 1.0.2 introduced the (by know well known) sandbox model, where downloaded code (applets) can access only very limited resources on the client's machine. JDK 1.1 had an all or nothing approach, where signed applets were treated as (a client's) local code, while unsigned applets were restricted to the sandbox. JDK 1.2 now introduces fine-grained access control, configurable security policies, and extensible access control structures. In a nutshell, a security policy defines the set of permissions of each downloaded applet depending on the set of principals which signed the applet. A permission, for example, is access to a particular file on the client machine. The authors expect that there will be a software layer between the JDK and the end user, which provides the user with a choice of pre-defined, sensible security policies.

The paper by Poger and Baker (both of Stanford University) described SPINACH (Secure Public Internet ACcess Handler), a system that controls access to computer networks via publicy accessible LANs. The new Stanford Computer Science building has a number of public ports, from which only authorized users should be able to tap into the department and university networks. SPINACH provides access control to these networks via a self configuring router, controlling per-user accesses from the public subnet to a private one. It also provides a mechanism for users to prove themselves as authorized so that they can have full network access. The design of SPINACH took care so that only standard protocols and software is used and only requires minimal software on users' machines.

The paper by Matias, Mayer, and Silberschatz (all of Bell Labs / Lucent) considers a new security framework for low-cost transactions, which execute in the context of an ongoing, extended client-server relationships. For example, a Web-site which offers personalized and authenticated stock quotes to each of its subscribers. The framework is focused on minimizing the cryptographic costs on the server side and at the same time enabling mobility on the client side via transparent key management. Cryptographic costs on the server is currently a central issue as people realize the cost of protocols, such as SET. Even SSL, in the case where a client changes machines and a new handshake is required, carries non- neglible cost. At the same time, clients increasingly move from PCs at work to labtops when traveling and, in the future, to Internet kiosk in airports and hotels. Thus, client mobility is definitely required. The authors suggest that this new framework could be used on VPN's and Intranets, or, alternatively, it could be integrated into SSL making it less exepensive for servers and enabling mobility for clients.